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FOREWORD 


This  handbook  is  part  of  an  overaJJ  efiort  to  establish  and  maintain  a 
high  level  of  expertise  in  our  program  business  management  operations.  The 
ability  to  apply  and  analyze  various  scheduling  techniques  is  an  absolute 
necessity  in  doing  our  job  of  developing,  producing,  and  delivering  defense 
systems.  We  must  relate  schedules  of  a  myriad  of  activities  and  partici¬ 
pating  organizations  to  accomplish  this  program  management  job  success¬ 
fully.  Our  intent  here  is  to  present  some  basics  and  practical  approaches 
that  will  serve  as  an  initial  training  aid  and  give  a  roadmap  of  procedures  to 
integrate  program  office  schedule  information. 

Ttie  key  concepts  here  are  the  quantification  and  interrelation  of  the 
schedule  characteristics  of  program  tasks  through  a  systems  approach.  This 
systems  approach  is  simply  an  explicit  structure  that  ties  together  the 
engineering,  financial,  logistics,  contracts  and  other  functional  perspectives 
of  a  program.  The  ideas  presented  are  workable,  but  we  need  more 
feedback  on  tailoring  schedule  systems  to  individual  program  circumstances 
and  information  needs.  Submit  your  suggestions  to: 


C  omptrolJer 

Business_Management  Division  (ESD/ACBB) 
\ir  Force  Base,  MA  01731 


BCT 

Colonel, 
Comptroller 
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Purpose 


Chapter  One 
INTRODUCTION 


This  handbook  is  designed  to  help  those  responsible  for  developing  and 
analyzing  schedules  ol  activities  for  programs  in  the  defense  system  acquisition 
process.  Our  aim  is  not  to  replace  the  more  detailed  and  comprehensive 
treatments  on  si  heduiing  topics  that  are  available,  but  to  give  a  condensed 
presentation  of  scheduling  and  analysis  techniques  and  organize  them  in  a  practical 
approach  to  solving  typical  program  office  scheduling  problems.  The  examples 
used  will  draw  heavily  on  ar  tual  experience  with  acquisition  programs  at  the 
Electronic  Systems  Division  (ESD). 

Background 

The  terms  "scheduling"  and  "schedule  performance"  may  seem  a  little  arti¬ 
ficial  to  those  who  have  dealt  with  management  problems.  There  is  no  real  way  to 
completely  separate  a  set  of  tasks  called  scheduling  and  assign  them  to  an 
individual  along  with  the  responsibility  for  schedule  performance.  Schedules  are 
products  of  the  planning  process  that  lay  out  the  expected  time-frame  of 
performance  of  activities  needed  to  accomplish  program  objectives.  Whether  they 
occur  "on-time"  depends  on  how  well  each  task  is  understood,  in  terms  of  technical 
specification  and  resources  needed,  and  if  the  interrelationships  with  other  tasks 
are  known  completely. 

Scheduling  is  the  process  of  obtaining  the  information  on  how  long  a  job 
should  take,  relating  it  to  the  other  jobs  required  to  deliver  the  product,  and  laying 
out  this  data  in  a  specific  format  to  show  when  it  must  be  done  to  fit  all  the 
constraints  we  know  about.  That  sounds  fairly  simple,  but  historically,  in  defense 
and  every  other  business,  the  track  record  is  not  good. 

An  analysis  of  our  collective  ability  to  schedule  activities  was  presented  as 
one  of  "Augustines  Laws"  by  Norman  R.  Augustine  in  the  Spring  1979  Defense 
Systems  Management  Review  (page  55).  Based  on  his  own  considerable  experience 
in  government  and  industry,  he  derives  the  "fantasy  factor"  that  predicts  any 
activity  will  take  one-third  more  time  than  is  currently  estimated.  Unfortunately, 
something  close  to  that  factor  seems  to  crop  up  in  many  programs.  We  believe 
that  the  track  record  can  be  improved  by  establishing  a  clear  set  of  groundrules  for 
scheduling  activities  (style,  approach,  techniques)  and  applying  them  consistently. 

Schedules  of  activities  and  events  form  one  ol  the  basic  languages  we  use  to 
communicate  to  get  the  job  done.  We  "commit"  to  schedules  by  negotiating  with 
our  bosses;  all  plans  and  budgets  are  meaningless  without  the  schedule  relating  the 
technical  product  and  the  cost.  Especially  in  our  business  of  developing  and 
delivering  defense  systems,  when  the  new  capability  can  be  put  to  use  is  of 
supreme  importance. 


1-1 


We  include  scheduling  as  one  ol  the  six  1  unctions  of  Business  Management  in 
the  sense  that  it  is  a  subset  of  the  tools  needed  to  apply  a  disciplined  approach  to 
piogram  management.  Schedules  are  also  a  major  part  of  our  officially  directed 
Program  Baseline,  in  other  words,  our  contract  with  Hq  AFSC  and  Hq  Air  Force  to 
deliver  a  specific  product  within  cost  and  schedule  constraints. 

With  the  heavy  en  phasis  on  Program  Baseline  Management  (AFSCR  550-18), 
the  credibility  of  our  schedule  baseline  is  receiving  increased  attention.  The 
technical  (or  product  performance)  baseline  and  the  cost  and  schedule  baselines  are 
the  three  major  quantities  of  the  program  management  proce  >s.  Each  is  but  one 
dimension  of  a  three  dimensional  whole.  A  change  in  any  one  of  the  dimensions 
means  that  the  basic  program  has  been  modified  and  the  other  two  will  be  changed 
as  well.  There  is  no  way  to  describe  a  schedule  problem  without  including  the 
technical  and  cost  impai  ts.  The  key  is  to  define  the  relationships  linking  technical, 
cost,  and  schedule  during  the  major  planning  efforts  and  as  plani  are  updated. 

Past  performance  in  the  area  of  scheduling  has  been  criticized  by  the  AFSC' 
Inspector  General  (1G)  and  Program  Management  Assistance  Group  (PMAG)  in 
reviews  here  at  ESD  and  at  the  other  AFSC  product  divisions.  The  recurring 
problems  cited  include: 

1.  Lack  of  a  Program  Master  Schedule  that  integrates  all  major  program 
activities,  major  decision  points,  and  officially  directed  program  milestone  dates. 

2.  Schedules  of  major  activities  are  not  backed  up  by  more  detailed 
schedules  of  lower  level  activities. 

3.  Schedule  uncertainty  and  risk  analysis  is  minimal. 

4.  Schedule  changes  (contractions  or  extensions)  are  not  analyzed  to  guage 
cost  and  technical  impacts. 

5.  Contractor  developed  schedules  are  not  given  an  independent  analysis  for 
credibility. 

These  problems  exist  for  a  number  of  reasons  but  we  feel  that  the  chief 
causes  are:  (1)  a  lack  of  staff  guidance  and  followups,  (2)  a  lack  of  working  level 
knowledge  of  scheduling  techniques  and  applications,  and  (3)  an  overall  tendency  to 
downplay  the  importance  of  schedule  planning  in  favor  of  cost  and  technical  effort. 
Our  attempt  here  is  a  modest  start  to  describe  schedule  characteristics  as  just  one 
indispensible  part  of  good  planning  and  analysis.  We  hope  to  increase  the  working 
vocabulary  of  our  program  management  language  to  allow  straight-forward  com¬ 
munication  on  such  topics  as  network  constraints,  uncertainty  calculations,  and  the 
quantification  of  risks  and  impacts  of  changes. 

Scope 

As  stated  earlier,  we  are  not  attempting  to  present  a  self-sufficient 
treatment  of  tile  topics  covered.  There  are  many  good  detailed  sources  for  basic 
schedule  techniques,  and  we  assume  that  most  readers  have  been  exposed  to  some 
of  them  in  previous  technical  and  business  oriented  courses.  (A  list  of  references 
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will  be  given  at  the  end  of  each  chapter.)  Each  chapter  will  give  a  basic  refresher 
on  the  techniques  and  then  present  some  application  cautions  (strengths  and 
weaknesses)  and  examples.  This  procedure  will  be  used  for  the  next  four  chapters 
covering:  Gantt  Charts,  Milestone  Schedules,  Networks,  and  Line  of  Balance. 
Then,  in  Chapter  6,  we  will  present  a  practical  method  for  developing  a  Program 
Master  Schedule  based  on  a  technique  that  allows  easy  modification  to  a  large- 
scale  network  and  lets  us  concentrate  on  the  planning  process  and  not  the 
mechanics.  Chapter  7  will  expand  the  Master  Schedule  by  looking  at  the  need  for 
Intermediate  Schedules  which  break  down  major  activities  into  the  key  component 
activities  along  with  the  identification  of  those  responsible  for  completing  them. 
Finally,  Chapter  8  concentrates  on  techniques  to  quantify  schedule  uncertainty 
from  the  basic  time  estimates  for  each  activity  in  a  network.  This  last  chapter 
draws  from  a  number  of  sources  and  is  a  much  more  mathematical  treatment  than 
the  rest  of  the  handbook.  It  is  intended  for  specialized  applications  such  as 
Independent  Schedule  Assessments  (AFSCR  800-35). 


Chapter  One  References 
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Chapter  Two 
GANTT  TECHNIQUES 


Descript  ion 

One  of  ttie  earliest  approaches  to  schedule  planning  control  is  a 
technique  known  as  Gantt  Charts.  Named  after  its  developer,  Henry  L. 
Gantt,  the  Gantt  Chart  was  originated  to  help  Frederick  Taylor  (The  father 
of  scientific  management)  display  information  for  work  planning  and  con¬ 
trol.  The  set  ot  Gantt  techniques  evolved  into  effective  planning  and 
monitoring  tools  for  operations  involving  many  tasks. 

The  i  oncept  of  Gantt  Charting  is  relatively  simple.  Down  the  vertical 
axis  are  listed  the  subjects  of  interest.  The  subjects  may  be  tasks, 
organizations,  or  people.  The  horizontal  axis  is  used  to  portray  time 
according  to  some  scale.  Usually  a  bar  depicts  the  length  of  a  particular 
activity. 

As  an  example,  suppose  we  want  to  chart  the  major  activities  of 
business  management  people  for  the  next  year.  The  people  become  the 
subject  and  their  planned  activities  might  appear  as  follows: 


STAFF 


MR.  SMITH 
M A3  JONES 
MS  BROWN 
CAPT  WHITE 
CAPT  MASON] 
MS  LEGG 


JAN,  FEB,  MAR,  A  PR  ,  MAY.3UN  ,  3UL  .  Al  G.SliP,  OCT,  NOV,  DEC 

log  confI  IdsmcI  [la] 

[source  selection  I  (afiTI 


VALIDATION]  IF1N  REVIEW!  |VALID  Rl  VIEW)  [PROJECT  X\ 


SOURCE  SELECTIONl  ISOURCE  SEL!  CTlO^l 

|LEAVEl 

ora 


.ELECTION  SUPPORT  REV1EW1 


Figure  1 


At  the  beginning  of  the  year,  Mr.  Smith  blocked  out  the  major  commit¬ 
ments  of  his  people.  He  could  have  attached  the  planning  process  from  the  task 
end  as  well: 
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_\i  T1  VITil-S  j  3AN  |  FEB  t  M  AK  ,  APR  { MAY,  .'HJN  ,  ]l  L,  A1JG,SEP|  OCT,  NOV,  DEC 

SOURCE  r~ 

SELECIION  L- 

LOGISTICS 
CONFERENCE 

VALIDATION 


I’M P  REVISION 


FINANCIAL 
R  E  VI  EM 

Figure  2 

The  time  scale  shown  is  the  one  most  meaningful.  The  scale  can  be  in 
months,  days,  or  whatever.  Sometimes  the  bars  represent  successive 
activities  where  one  must  be  completed  before  the  next  .tarts,  as  in  Figure 
3. 
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Figure  3 


Gantt  Charts  with  these  characteristics  are  for  obvious  reasons  often 
called  waterfall  charts. 


There  are  a  number  of  innovations  to  make  Gantt  Charts  more  useful; 
some  of  the  more  popular  techniques  are: 

(1)  Block  shading  to  show  progress. 


TASK  A  Wy///////A  ~ '  □  (Task  50%  Complete) 
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p 


(2)  SI i.  w  "as  of"  date  with  a  verti<  al  line 

I 

TASK  A  C - -  j  ^ 

TASK  B  I  r-~~  J 

TASK  C  L  |  ZD 

TASK  D  l _ |_ZZD 


(3)  Annotate  with  explanatory  symbols 

TASK  A  \  . . j  bs 

TASK  B  |  c 

TASK  C  J  as 

TASK  D  |  1 _ 1  fs 


Behind  Schedule 
Complete 
Ahead  of  Schedule 
Future  Start 


Strengths 

Perhaps  the  greatest  asset  of  a  Gantt  Chart  is  its  simplicity  both  to 
construct  and  to  communicate  information.  They  are  easy  to  develop  and 
update  and  the  mechanics  are  compatible  with  pen  and  pencil  or  computer 
controlled  automatic  plotters  working  from  a  data  base.  The  sophistication 
depends  on  the  purpose  and  the  size  of  the  job,  but  do  not  let  color-coded 
window  dressing  influence  your  assessment  of  what  is  needed.  Grease  pencil 
on  wall  charts  have  been  very  successful  and  the  fancy  presentations  require 
many  hours  of  preparation. 


The  Gantt  technique  is  quite  good  for  showing  the  summary  levels  of  a 
total  program  which  will  give  a  quick  one  page  reference  for  the  phasing  of 
all  major  program  activities.  They  are  also  very  useful  for  expanding  a 
single  schedule  task  into  the  detailed  activities  that  make  it  up.  An 
example  would  be  to  show  the  time  phasing  of  effort  for  the  key  people 
necessary  to  complete  an  activity.  (This  will  come  in  handy  when  we  cover 
Intermediate  Schedules  in  Chapter  7.) 


Figure  4  is  an  example  of  a  repetitive  process,  the  budget  cycle,  that 
has  at  least  three  different  fiscal  years  being  worked  at  any  one  time.  The 
Gantt  display  shows  this  relationship  quickly  and  simply. 
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Figure  4 


The  Gantt  technique  works  well  if  the  activities  scheduled  are  a  fairly 
constant  level  of  effort  or  a  fixed  resource  that  is  being  used  to  support 
multiple  activities,  such  as  test  facilities  or  equipment.  For  more  complex 
acmitiesthe  Gantt  Cha  t  has  limited  capability. 

Weaknesses 

This  brings  us  to  what  the  Gantt  Charts  are  not  good  for  and  the 
greatest  weakness  is  the  inability  to  show  interactions  between  activities 
ex.  ept  on  a  very  simple  level.  Don't  try  to  use  a  Gantt  display  to  lay  out 
thi  detailed  planning  for  any  phase  of  a  program.  As  soon  as  the  numbei  of 
activities  be.  ornes  large  (say  more  than  a  dozen)  the  Gantt  Chart  will  cause 
more  questions  to  be  asked  than  answered  about  the  relationship  between 
tasks. 
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Tin",  also  foil  short  \  lion  used  to  schedule  .u  tivities  that  are  .  ompli- 
*  ated  in  nature.  1'his  is  c  jX-eially  true  when  the  progress  display  feature  is 
being  u sihI.  In  other  won  is,  when  the  activity  is  not  host  discribed  by  the 
mere  passage  ot  tune  Iron  start  to  finish,  then  a  Gantt  display  cun  be  a 
very  misleading  way  to  i  lonitor  performance.  The  following  are  a  few 
examples  of  the  confusion  that  can  arise. 


1.  The  task  is  Iron  -loadei 
resources  required. 


in  terms  of  the  effort  and  material 


75%  Complete 


I 


time  now  (30%  of  elapsed  time) 


The  display  shows  an  ahead  of  schedule  situation  when  it  is  in  fact  on-time; 
it  should  be  75%  complete  at  this  point.  In  some  cases  it  could  be  behind 
schedule  depending  on  how  front-loaded  the  task  is. 

2.  The  bulk  of  activity  is  required  toward  the  end  of  a  task. 


30%  Complete 


I 


time  now  (50%  of  elapsed  time) 


The  task  may  be  ahead  of  schedule,  but  shows  up  as  late. 

The  point  is  that  a  Gantt  technique  is  not  designed  to  easily  show 
completion  progress  on  complex  tasks  and  you  can  spend  a  great  deal  of 
time  explaining  artificial  performance  variances  which  detracts  from  the 
analysis  of  the  real  situation. 

The  Gantt  approach  is  also  deficient  in  showing  actual  performance 
versus  the  original  planned  schedule  baseline.  If  the  start  and  completion 
dates  are  different  than  the  plan,  there  is  no  simple  way  to  display  that 
information.  This  leads  to  the  next  chapter  on  Milestone  Schedules  which  is 
a  modification  of  the  Gantt  Technique. 


MILESTONE  SCH  EDI  I  LI'S 


Introduction 

B\  (dr  the  most  common  scheduling  technique  at  ESD  is  the  milestone 
i  hart.  Milestone  schedules  are  prepared  by  the  conti  actors  as  a  contract 
data  item  or  used  by  the  SPO  for  a  myriad  of  planning  purposes.  They  are 
required  for  the  Command  Assessment  Review  (CAR)  and  Program  Financial 
Reviews  for  Hq  AFSC,  and  for  a  host  of  other  briefings.  A  week  does  not  go 
by  within  a  typical  SPO  without  the  requirement  to  update  and  prepare  a  set 
of  milestone  charts  for  one  reason  or  another. 

The  milestone  technique  itself  is  quite  simple.  For  a  particular 
activity,  a  set  of  key  events  are  selected.  A  milestone  is  an  event  that 
should  occur  if  a  particular  activity  is  to  proceed  as  planned.  In  Figure  5 
the  activity  being  scheduled  is  the  engineering  development  phase  of  an  ESD 
project.  Milestones  were  selected  based  upon  the  SPOs  plan  for 
accomplishing  the  engineering  development  phase.  By  reviewing  the  status 
of  those  milestones,  we  can  assess  the  overall  schedule  status  of  this 
activity. 

Description 

The  milestone  type  of  schedule  uses  a  fairly  standard  symbology 
consisting  of  arrows  and  diamonds,  or  some  similar  system,  to  show 
originally  planned  event  dates  and  changed  dates.  Figure  6  shows  the 
symbols  we  use  on  the  AFSC  Form  103,  Program  Schedule,  and  the 
interpretation  of  various  combinations  of  the  symbols. 

Figure  5  shows  the  application  of  the  symbology  from  Figure  6.  Line 
4,  ADPE  Installation  and  Check  out,  was  completed  one  month  ahead  of 
schedule.  Both  lines  6  and  7,  Equipment  Integration  and  Software  Develop¬ 
ment  were  initiated  one  month  behind  schedule.  The  diamond  symbol  can  be 
used  to  show  events  that  are  rescheduled  to  account  lor  changes  as  a 
program  progresses  while  the  diamonds  retain  the  ciginally  planned 
schedule.  So  the  milestone  schedule  allows  us  to  improve  o  i  the  Gantt  chart 
by  monitoring  actual  performance,  retaining  the  baseline  dates,  and  incorpo¬ 
rating  changes  in  the  plans  for  future  events. 

Note  that  the  milestone  scheduling  technique  is  limited  to  telling  us 
what  has  happened  or  incorporating  changes  in  plans  projected  from  other 
sources.  It  is  not  very  useful  for  forecasting  future  schedule  changes  like 
the  Network  or  Line  of  Balance  techniques  that  we  will  cover  in  the  next 
two  chapters.  The  milestone  schedule  simply  records  the  manager's 
assessment.  For  example,  a  manager  might  reasonably  predict  that  the  one 
month  slip  in  the  start  of  software  development  will  probably  result  in  at 
least  a  one  month  slip  in  the  completion  of  the  engineering  development 


SYMBOLOGY  AND  USE 


Standard  symbols  have  been  adapted  for  Air  Force  Milestone 
Schedules.  The  most  common  symbols  use  and  their  meanings  are  shown 
below: 


BASIC  SYMBOL  MEANING 


o 


Schedule  Completion 


Actual  Completion 


O 

♦ 

REPRESENTATIVE  USES 


o  o 

♦  o 

♦  t 

t  o 

<ti> 

H _ c> 


Previous  Scheduled  Completion-Still  in 
Future 

Previous  Scheduled  Completion-Date 
Passed 

MEANING 

Anticipated  Slip-Rescheduled  Completion 
Actual  Slip-Rescheduled  Completion 
Actual  Slip- Actual  Completion 
Actual  Completion  Ahead  of  Schedule 
Time  Span  Action 
Progress  Along  Time  Span 
Continuous  Action 


Figure  6  (from  AFSCR  27-6,  Sep  7*f) 
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phase.  The  milestone  schedule  does  not  tell  him  that  his  experience  does. 
This  is  4<-y  to  understanding  the  use  ol  milestone  charts.  Unless  we 
understand  the  activity  and  the  mtert elationships  of  the  milestones,  the 
chart  only  tells  you  what  has  happened.  However,  >f  we  couple  the 
information  on  what  has  happened  to  the  available  <  xpt  rience/kriowledge, 
we  can  determine  what  may  happen  in  the  future. 

Milestone  c  harts  are  also  used  to  lay  out  the  detailed  scheduling  within 
most  contractor  (Jcst/Schedule  Control  Systems.  This  includes  planning  and 
performance  measurement  down  to  the  level* of  indivicual  work  units  or 
packages  which  can  number  in  the  tens  of  thousands  on  a  large  contract. 
This  quite  naturally  leads  to  an  automated  system  and  the  milestone 
approach  is  very  amenable  to  a  computer  treatment.  However,  heed  the 
cautions  m  the  last  section  on  automated  milestone  systems. 

Structur i 1 _M i k-stone  Schedule  System 

For  a  complete  large-scale  milestone  system  tl  e  key  is  a  well 
structured  organization  of  the  various  levels  of  activitie,  scheduled.  This 
structure  must  relate  to  both  the  product  (equipment  a  id  services)  to  be 
delivered  and  to  the  organizations  (or  individuals)  responsiole  for  performing 
the  work  required.  A  structure  that  accomplishes  these  requirements  is 
necessary  to  fulfill  the  DOD  Cost/Schedule  Control  Systems  Criteria 
(C/SCSC)(see  AFLCP/AFSCP  17  3-5  C/SCSC  Joint  Implementation  Guide, 
p.  14)  for  contractor  applications.  The  basic  framework  is  the  Program  Work 
breakdown  Structure  (PWBS)  which  is  the  product  oriented  description  of 
the  total  job  to  be  done.  Military  Standard  881 A  explau  s  the  WBS  and  its 
application  to  the  generic  types  of  defense  systems  (ele<  tronic  systems  for 
ESD).  AFR  800-17  implements  ths  MIL  STD  for  Air  Force  a- quisition 
programs. 

The  PWBS  describes  the  program  in  levels  where  level  one  is  the 
system  to  be  delivered,  level  two  divides  this  into  the  major  system 
equipment  and  services  (Prime  Mission  Equipment,  System  Test  and  Evalu¬ 
ation,  System/Project  Management,  Data,  etc.).  Level  three  expands  each 
level  two  item  into  its  major  components,  and  each  succeeding  level  adds 
more  detail  to  form  a  tree  structure.  Many  Contract  WBSs  extend  to  level 
six  or  lower,  which  can  encompass  individual  WBS  items  numbering  in  the 
thousands. 

The  Responsibility  Assignment  Matrix  concept  adapted  from  C/SCSC 
links  the  performing  organizations  with  the  parts  of  ihe  WBS  they  are 
responsible  for.  This  can  be  used  for  both  total  Program  and  Contract 
WBS's,  but  remember,  the  various  contracts  can  only  form  a  subset  of  the 
total  program  activities  that  a  PWBS  must  describe. 

The  milestone  schedules  are  used  to  lay  out  the  activities  and  events 
in  any  of  a  number  of  cross-sections  from  this  matrix.  Figure  7  shows  a  part 
of  a  Progi^m  WBS  Responsibility  Assignment  Matrix.  The  intersections 
identify  both  the  work  and  the  workers  and  schedules  can  then  be  called  out 
by  responsible  organization,  by  WBS  item,  or  both.  The  level  of  detail  is 
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RESPONS1BII  ITY  ASSIGNMENT  MATRIX 


Responsible  Organizations 


Work  Breakdown 
Structure 
Level: 

_l_ 

System  ZX 

Prime  Mission  Equip. - 

Integration  &  Assem 

Radar - - - 

Commun.  Equip. 

ADP.  Equip. - 

Software - 

Displays  - _ 

Auxiliary  Equip. 

Training 
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Equipment 
Services  — 
Facilities  - 


Peculiar  Support  Equip.  — 


Systems  Test  &  Eval. 

Development  Tests 
Operational  Tests  - 
Test  Support  .  -  — 

System/Prograrn  Mgt.  - 
System  Engr.  —  — 

Project  Mgt. - - 

ILS -  - 

Data  - —  — - - 

Site  Activation 
Common  Supp.  Equip.  — 
Initial  Spares  - - 


Figure  7 
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varied  by  the  WBS  level  required.  As  stated  earlier,  the  contra'  tor 
application  of  this  system  will  iri<  lude  schedules  at  levels  five  and  six  of 
work  planning  and  performance  in  many  areas  of  the  WBS.  The  Program 
Office  application  will  normally  be  limited  to  a  higher  level  for  practical 
maintenance  of  the  system.  (See  Chapter  7  on  Intermediate  Schedules  for 
more  guidance.) 

Strengths 

As  with  the  Gantt  chart,  the  milestone  schedule  can  bo  a  very 
effective  method  of  communication.  The  symbology  is  relatively  standard 
and  simple  to  use.  It  also  allows  the  presentation  of  actual  progress  against 
a  baseline  plan  and  changes  in  future  plans.  The  mechanics  to  construct 
milestone  schedules  are  also  relatively  simple,  although  it  may  seem  that  we 
spend  too  much  of  our  time  with  stick-on  arrows  and  diamonds  and  the 
AFSC  Form  103.  \s  described  earlier  most  of  our  contractors  use  milestone 
schedules  extensively  and  they  are  usually  the  type  submitted  for  the 
Program  Schedule  contract  data  item  (data  item  description  (DID)  DI- 
A3007)  as  well  as  their  use  in  the  Cost/Schedule  Control  Systems. 

One  very  useful  adaptation  has  been  used  for  work  performance 
measurement.  This  technique  is  shown  in  Figure  8  below  and  consists  of  a 
number  of  significant  milestone  points  for  an  activity  that  correspond  to 
some  mensureable  interim  completion  values.  These  are  called  "value 
milestones"  and  in  this  example  the  first  milestone  accomplishment  repre¬ 
sented  15%  completion  after  all  purchased  parts  an  received  to  begin 
assembly.  The  second  milestone  increases  to  a  65%  completion  as  major 
subassemblies  are  all  completed.  This  continues  to  100%  after  completion 
of  final  tests. 

Component  Assembly  and  Checkout 

0%  15%  65%  80%  100% 

f - * - - * 

i  |  i 

i  i  ,  i 

START  PURCHASED  J  |  TESTING  COMPLETE 

PARTS  RECEIVED  |  TOTAL  ASSEMBLY  COMPLETE 

SUBASSEMBLY  MANUFACTURING 
COMPLETE 

Figure  8 


As  these  more  complex  applications  of  milestone  schedules  are  encoun¬ 
tered  we  must  remember  that  this  scheduling  approach  is  giving  us  a  limited 
view  of  what  is  in  fact  a  network  of  activities.  Milestone  charts  are  used  to 
portra\  results  derived  from  network  analysis  or  a  line  of  balance  computa¬ 
tion  which  is  a  variation  of  networking.  We  will  cover  these  in  the  following 
chapters,  but  this  points  up  the  deficiencies  of  the  milestone  approach  that 
we  must  keep  in  mind. 


Weakiu  ses 

As  with  the  Cantt  chart,  a  m.i  >r  weakness  of  the  milestone  technique 
is  the  luck  of  a  mechanism  to  how  interdependencies  or  interui  tion 
between  activities.  Although  mile  tone  schedules  are  used  extensively  on 
complex  programs,  they  are  usually  the  product  of  some  type  of  network 
analysis.  In  fact,  the  milestone  technique  is  a  good  way  to  display  various 
areas  ol  a  network  in  a  more  familiar  form,  and  we  will  look  at  this  concept 
in  detail  in  Chapter  7  on  Intermediate  Schedules.  The  danger  lies  in  our 
tendency  to  focus  on  the  milestone  format  and  lose  sight  of  the  true 
complexity  of  the  relationship  between  the  tasks  we  are  dealing  with  and 
the  total  program. 

The  Responsibility  Assignment  Matrix  structure  discussed  earlier  does 
give  us  a  way  to  relate  a  large  number  of  milestone  events,  but  this 
technique  is  simply  setting  up  the  first  stages  of  a  network  and  a  full 
network  teatment  should  back  it  up.  As  an  example  of  the  problems  with 
the  stm  t  milestone  treatment,  look  at  Figure  7  again.  A  milestone 
schedule  that  shows  all  of  the  major  events  for  the  WHS  item  Systems  Test 
and  Evaluation,  Development  Tests  is  backed  up  by  func  tional  schedules 
from  seven  responsible  organizations.  Each  of  these  organizations  must 
accomplish  certain  key  activities  to  complete  testing  lor  this  system.  The 
milestone  technique  will  not  tell  us  what  the  sequence  of  activities  must  be, 
where  the  constraining  points  are,  and  which  activities  are  most  critical  for 
management  attention.  In  fact,  there  will  be  many  opii  ions  about  the  above 
information,  but  the  manager  will  be  left  to  sort  it  out.  The  milestone 
technique  will  not  show  it  to  us. 

This  type  of  problem  becomes  non-trivial  quickly  as  the  WBS  level  being 
scheduled  increases.  There  is  an  ever-present  danger  that  activities  which 
show  up  on  product  (WBS)  oriented  schedules  and  on  several  different 
functional  schedules  may  change  in  one  place  while  the  impact  in  other 
areas  is  not  realized  until  too  late.  Again,  milestones  do  not  depict 
interactions,  the  manager  must  find  them  out. 

Most  programs  require  the  contractor  to  submit  nilestone  schedules. 
The  contractor  is  generally  expected  to  select  the  mi  estones  which  he  or 
she  believes  will  indicate  the  overall  status  of  activiiies.  The  data  item 
description  normally  allows  the  government  to  approve  of  the  milestones 
which  are  selected  for  periodic  reporting.  BEWARE!  There  are  many  traps 
in  this  area.  First,  do  not  let  the  contractor  report  milestones  which  no  one 
in  the  SI’O  understands.  Avoid  cryptic  abbreviations.  Avoid  generating  a 
host  of  a  phabet  soup.  The  schedule  is  meant  to  communicate  information. 
It  can  not  do  that  without  careful  selection  of  the  milestones.  If  you  don't 
understand  every  line  in  a  contractor's  schedule  have  it  explained  to  you. 

Another  danger  to  avoid  is  the  tendency  for  "micro-management."  For 
example,  one  of  the  writers  had  a  contract  with  a  large  contractor  who  had 
automated  a  technique  for  producing  milestone  schedules.  Working  with  the 
SPO,  generic  milestones  were  identified  for  report)  ig.  Since  the  SPO 
software  engineers  had  expressed  a  requirement  foi  Computer  Program 
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Component  (C PC)  level  visibility  below  the  Computer  Program  Configura¬ 
tion  Item  (CPC1)  evel,  a  generic  set  of  eight  milestones  were  selected  for 
each  CPC.  Milestones  such  as  start  and  complete  design,  and'  start  and 
complete  coding  were  at  first  considered  reasonable  types  of  milestones. 
Not  until  the  SPO  had  let  the  contractor  implement  this  type  of  schedule  did 
we  realize  that  there  were  more  than  400  CPCs  and  that  the  software 
milestones  would  therefore  number  3200.  Similar  mistakes  were  made  in 
other  disciplines  with  a  net  result  of  a  program  milestone  schedule  which 
had  10,000  events.  Needless  to  say,  the  presence  of  so  many  "trees" 
prevented  anyone  from  even  finding  the  "forest."  Remember,  micro- 
management  can  kill. 

Select  milestjiies  by  having  each  functional  Division  Chief  determine 
what  he  or  she  coi  siders  important.  Keep  count  of  the  milestones  that  he  is 
requesting  and  avoid  the  CPC  reporting  problem  above.  Get  feedback  on 
the  utility  of  the  first  few  schedules  from  each  division  and  revise  the 
schedule  accordingly.  Work  closely  with  the  contractor  in  developing  a 
schedule  which  will  communicate  information.  Your  requests  for  changes  to 
the  contractor's  submission  can  be  made  as  part  of  your  official  comments 
on  the  data  item. 

Another  problem  with  milestone  schedules  is  in  determing  whether  the 
time  depicted  for  an  activity  is  reasonable.  Past  experience  on  other 
programs  or  independent  assessments  by  the  SPO  divisions  are  good  tech¬ 
niques,  but  tend  tc  be  subjective  because  of  the  lack  of  a  credible  data  base 
of  historical  experience.  However,  if  your  contract  requires  a  Cost 
Performance  Report  (CPR)  and  the  validation  of  the  contractor's  C/SCSC 
system,  there  is  another  method  for  determing  the  reasonableness  of  a 
particular  schedule. 

The  contrac  tor's  C/SCSC  system  is  required  to  have  a  scheduling 
system  which  meets  certain  criteria.  An  essential  criterion  is  the  ability  for 
schedules  at  the  work  package  level  to  support  and  track  to  the  schedules  at 
the  cost  account  level.  Similarly,  the  cost  account  schedules  must  support 
and  track  to  the  intermediate  schedules  and  to  the  master  schedule.  For 
any  item  on  the  milestone  schedule,  the  contractor  should  be  able  to 
demonstrate  that  lower  level  schedules  support  this  item.  These  lower  level 
schedules  can  be  i  eviewed  upon  request.  If  you  are  lucky  enough  to  have  a 
data  accession  clause  on  your  contract,  you  can  also  request  copies  of  the 
lower  level  si  hedjles  which  support  a  particular  item.  However,  beware 
once  again  ol  micro-management.  A  $40M  contract  can  have  over  5,000 
work  packages  -  each  with  a  schedule.  Insure  that  you  use  these  requests 
sparingly  to  support  a  one-time  review  of  a  critical  area.  Do  not  allow 
yourself  to  get  dragged  into  the  trees.  On  the  other  hand,  don't  be  afraid  to 
use  this  dat£.  Spot  checks  help  insure  that  the  contractor's  schedules  are 
credible. 

Most  milestone  schedules  from  the  contractor  contain  a  narrative 
describing  why  changes  occurred.  This  narrative  is  never  complete  and 
there  is  a  tendenc  y  for  SPO  Divisions  to  bombard  Business  Management  with 
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data  item  corn  men  ts  such  as  "Why  did  this  slip""  or  "Why  will  this  item  take 
three  m.  iths'.M'  Ho  not  accept  these  comments  blindly  and  forward  them  to 
the  coin  actor.  A  SPO  cannot  afford  to  communicate  with  the  contractor 
solely  or  even  primarily  through  the  monthly  schedule.  If  someone  has  a 
question,  let  him  call  his  counterpart  at  the  contractor's  and  ask  the 
question.  The  only  times  that  formal  questions  should  be  included  in  your 
data  comments  are  when  the  contractor  reluses  to  provide  an  informal 
answer  or  when  the  SPO  OPR  wants  the  answer  formally  documented  for 
some  reason.  These  questions  should  be  limited.  Answering  these  questions 
can  tie  t  p  a  significant  portion  of  the  contractor's  management  resources  - 
resource  that  could  probably  be  better  applied  elsewhere. 

Milestone  schedules  require  a  significant  amount  of  effort  to  generate. 
Searching  out  the  status  of  an  item  consumes  more  time  than  making  the 
chart.  Answering  questions  adds  to  the  time.  If  you  have  ever  developd  a 
set  ot  milestone  charts  for  a  Program  Financial  Review  or  for  an  internal 
review  you  can  quickly  appreciate  the  amount  of  effort  required.  Remem¬ 
ber  this  when  you  ask  the  contractor  to  do  something. 
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Chapter  Tour 
NETWORKING 

Introduction 

In  the  previous  chapters  we  have  frequently  cited  the  lack  of  a 
mechanism  to  show  the  interdependencies  of  schedule  activities  as  a  key 
weakness  of  the  Gantt  and  milestone  techniques.  Network  analysis  is 
designed  n  perform  precisely  that  function.  This  approach  diagrams  a 
schedule  b\  the  f low  of  activities  that  make  it  up  11  the  sequences  and 
patterns  that  actually  relate  the  tasks.  Network  techniques  are  indispens¬ 
able  to  s>  .i  ms  analysis  in  engineering  the  technical  aspects  of  our  systems. 
Applying  a  similar  approach  to  scheduling  is  simply  a  re  ognition  of  the 
c  omplexity  of  the  job  we  are  dealing  with. 

Before  we  even  begin  a  description  of  network  techniques  we  must  deal 
with  some  of  the  criticisms  of  them  as  management  tools  for  planning  and 
control.  There  is  no  escaping  the  fact  that  networking  is  a  major 
undertaking  for  any  program.  The  level  of  effort  is  h  gh  initially,  and  the 
questions  that  must  be  answered  to  identify  the  red  relationships  and 
constrain  s  between  program  tasks  will  involve  almost  every  individual  with 
a  respons  bility  to  do  a  job.  But,  the  process  of  constructing  the  network  in 
itself  will  prove  a  valuable  experience  to  the  program,  because  you  will  find 
that  many  channels  of  communication  will  be  opened  up  that  would  not  have 
existed  otherwise.  We  will  describe  this  process  in  more  detail  in  Chapter  6. 

Description 


The  term  "networking"  refers  to  any  of  a  group  of  techniques  that 
portray  the  elements  of  a  system  in  a  scheme  that  explicitly  defines  the 
relationships  between  the  elements  (i.e.  sequences  of  operations,  combina¬ 
tion  and  divergence  points,  and  the  operations  that  occur  between  points). 
When  applied  to  si  hedules  a  network  diagrams  the  activities  or  tasks  that 
are  required  and  relates  these  activities  in  terms  of  their  initiation  and 
completion  points.  As  with  the  milestone  approach,  any  single  activity  can 
usually  be  broken  down  into  the  subtasks  that  make  it  up,  or  a  group  of 
activities  can  be  aggregated  into  a  single  equivalent  schedule  task  with  one 
set  of  start  and  complete  milestone  events.  So  the  level  of  detail  can  be 
adjusted  to  fit  the  ipplication. 

The  first  use  of  network  analysis  for  scheduling  large  engineering 
projects  was  initialed  in  1956  by  private  industry  for  their  own  use  and  this 
was  quickly  followed  by  an  application  on  a  defense  development  program 
for  the  Nav\,  the  Meet  Ballistic  Missile  -  POLARIS.  The  initial  project  was 
called  the  Critical  Path  Method  U  PM)  and  the  Navy  application  was  the 
now  famous  (or  inf  irnous  -  depending,  on  your  viewpoint)  Program  Evaluation 
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and  Ki-vtew  Technique  (PERT).  Chapter  1  of  reference  l  gives  a  good 
account  of  these  developments. 


I’M.  T  and  CPM  are  both  1  air ly  standar  d  techniques  and  widely  used 
now.  There  is.  however,  a  gteai  amount  of  management  emotion  associated 
with  these  aitonyms,  both  pro  .nd  con.  We  will  not  get  involved  with  the 
controversy  at  this  point.  Both  are  very  similar  approac  hes  to  schedule 
netwiiks  and  that  is  our  subject  now.  Both  also  use  the  same  basic 
symbology  which  is  where  we  will  begin. 

Symbology 

The  basic  graphical  ingredients  for  a  network  ate  a  symbol  for  the 
"point  m  time"  events  or  milestones  that  start  and  stop  each  activity 
(usually  a  circle  or  box)  and  an  arrow  between  the  events  to  represent  the 
activity  itself.  The  direction  of  the  arrow  is  from  start  to  finish. 

To  start  with  an  example,  consider  the  activity  on  a  program  between 
the  initiation  of  the  effort  by  the  release  of  Program  Management  Direction 
(PMD)  by  Hq  LJSAF  and  the  first  desired  result— the  start  of  development 
work  by  a  contractor  at  contract  award  (CA).  The  network  description  is 
shown  below. 


We  have  two  milestones  and  the  activity  between  points  1  and  2  is 
estimated  at  27 5  days  to  complete.  Now  we  will  look  at  an  explode  J  view  of 
the  activity  to  show  a  complete  network  in  Figure  9. 

Tin  .  network  spans  the  same  initiation  and  completion  points  but  now 
there  at e  17  activities  and  15  events  describing  the  process  to  obtain  a 
contract  award.  The  events  are  numbered  so  that  any  activity  proceeds 
from  a  lower  number  (predecessor  event)  to  a  higher  number  (successor 
event).  An  activity  is  a  process  that  consumes  resources  over  a  period  of 
time.  The  movement  from  one  event  to  the  next  must  represent  progress 
towaid  the  final  goal;  if  it  does  not,  then  you  have  not  chosen  meaningful 
milestones  for  the  events.  The  only  exception  is  the  use  ol  "dummy 
activities,"  shown  by  a  dotted  arrow,  that  do  not  indicate  a  time  span— only 
a  dependency  between  events. 

Id  Figure  9,  the  activity  from  points  1  to  2  is  the  coordination  process 
at  Hcj  A1  SC  that  results  in  the  issuance  of  an  AFSC  Form  56  tasking  one  of 
the  i'roi  uct  Divisions  (here  ESD)  with  carrying  out  the  PMD  requirements. 
The  Duration  is  estimated  at  10  days.  Proceeding  through  the  network,  the 
AFS*  1  <ir«i  56  release  initiates  two  activities.  Activity  2-4  is  the  internal 
ESD  i  oordination  that  assigns  the  PMD  task  to  a  SPO  and  makes  an 
assc  .merit  of  resource  requirements;  the  result  is  the  initiation  of  the 
Pure  iuso  Request  (PR- AFS( '/AFLC  Form  36)  package  that  will  Define  the 
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'l>«'vifu  i  ontr.w  lual  requu ements.  A<  tivity  2-3  is  the  « * 1 1  or t  to  teliase  a 
Audgot  \uthoi  i/ation  (rum  Mq  AIS(  th.it  transmits  1 1  it-  funds  lor  the 
program  to  ESD  (tin*  overall  program  budget  requirements  would  base  been 
submitted  and  approved  prior  to  the  I’M  I")  release). 

Event  4  pieieeds  activities  4-i,  4-t>,  and  4-7  whir  h  are  in  sequence: 
preparation  and  <  oordmat ion  of  an  Acquisition  Plan  that  lays  out  the 
business  and  contract  strategy  for  tins  effort;  translating  the  program's 
technical  requirements  into  exact  contractual  language;  and  setting  the 
financial  requirements  (or  the  conit  a<  t  including  estimates  of  the  types  of 
hinds  and  the  time-phased  amount  needed  for  this  contract  eflort.  The 
tinal  <  oordmat  ion  of  the  Purchase  >Vquest  package  (point  9)  is  constrained 
by  the  approval  of  the  Acquisition  P  an,  in  this  r  ase. 

The  next  point  showing  dependency  is  point  II,  the  release  of  the 
Request  for  Proposal  (REP)  to  the  industry  source.  (The  REP  is  prepared  by 
the  Deputy  for  Contracts  based  on  the  PR  package.)  This  action  is 
constrained  by  the  receipt  of  the  Determination  and  Findings  (D&F), 
approved  by  the  Secretary  of  the  Air  Force,  which  grants  the  authority  to 
negotiate  a  contiact. 

A<  tivity  11-12  represents  the  30  day  period  lor  the  potential  <  ontractor 
to  prepare  trie  proposal.  Once  the  proposal  is  received,  there  is  frequently  a 
need  to  revise  our  assessment  of  the  financial  requirements  (activity  12-13). 
This  must  definitely  be  accomplished  before  negotiations  are  completed  and 
the  constraint  is  shown  by  dummy  activity  13-14.  The  final  task  (14-13)  is 
contrac  t  writing,  final  approval,  and  distribution.  (This  example  is  repre¬ 
sentative  of  pre-contract  award  activity  in  a  fairly  simple  case,  but  each 
activity  shown  here  could  be  broken  down  into  further  tasks  ant*  relation¬ 
ships.  Also,  the  tune  estimates  are  not  necessarily  accurate.) 

Network  Analysis 

With  the  basic  symbology  established,  we  can  now  start  t he  .aiulysis  of 
the  network.  This  will  be  an  abbreviated  treatment  of  the  subject  since  any 
of  the  sources  referenced  at  the  end  of  this  chapter  give  sever.  1  hundred 
pages  of  detail  and  applications.  You  will  find  many  other  sources  as  well. 

The  first  step  is  to  find  the  longest  path  through  the  netwc  rk,  and  in 
PERT  and  CPM  this  is  termed  the  "critical  path.”  For  the  exampk  in  Figure 
9,  the  critical  path  follows  points  1-2- 4- 5-8- 10-11-12-14-15  and  tl  *  duration 
is  275  days.  You  must  add  the  durations  sequentially  for  all  posi  ible  paths 
to  find  the  critical  path.  In  this  case  two  other  paths  are:  1-2-4-  -9-1 1-12- 
14-15  230  days,  and  1-2-3-7-9-11-12-14-15  =175  days. 

The  critical  path  in  a  network  becomes  the  focus  of  m.  nagement 
attention  because  any  slip  in  the  completion  of  an  activity  will  cause  an 
equal  slip  in  the  final  milestone,  assuming  that  the  other  activit  es  remain 
the  same.  With  the  same  logic,  a  decrease  in  the  duration  of  ai  y  critical 
path  a<  iivity  will  decrease  the  duration  of  the  entire  network.  That  is  true 
until  on"  or  more  of  the  other  possible  paths  takes  over  as  the  critual  path. 
That  introduces  the  next  key  concept  which  is  called  "slack  time." 


Sla«  k  lime  refers  to  the  difference  m  delation  between  the  critical 
path  and  an  alternate  path  at  any  point  in  the  network.  For  example,  in 
Figure  9,  the  black  in  path  I -2-4-6-9- 1  1 ,  at  pou  t  1  I ,  is  155-110  45  days. 
That  means  path  1-2-4-6  9-11  •  ould  increase  by  4 ")  days  belore  matching  the 
critical  path  length,  or  if  the  HAF  approval  (activity  8-10)  was  obtained  in 
40  days  instead  of  40,  then  it  would  no  longer  be  on  the  critical  path.  The 
slack  time  varies  at  each  point  in  the  network,  md  the  amount  of  slack  at 
the  stait  ot  any  activity  can  be  a  good  indicator  ol  the  importance  of  its 
schedule  performance  to  the  overall  project. 

For  a  large-scale  network  the  <  ritical  path  and  slack  time  calculations 
are  marie  by  what  are  called  "forward  pass"  and  "bai  kward  pass"  operations 
along  all  paths  of  the  network.  The  forward  pass  establishes  the  earliest 
expected  completion  (Lfi(')  dates  for  each  event  by  adding  the  expected 
activity  durations  to  that  point  (the  longest  time  is  used  lor  points  where 
several  paths  merge).  The  backward  pass  starts  at  the  final  event  and 
traces  the  paths  bark  to  the  start  point.  This  establishes  the  latest 
allowable  completion  (LAC)  date  for  each  event  by  subtracting  the  activity 
durations  from  the  LAC  for  the  previous  event.  The  difference  between  the 
earliest  expected  and  latest  allowable  completion  dates  at  each  point  is  the 
slack  ti  ue  for  that  point.  Along  the  critical  path  the  slack  is  zero.  (EEC 
and  LV  times  are  the  same). 

With  the  concept  of  slack  we  can  see  the  importance  of  the  estimates 
of  the  time  required  for  each  activity.  The  critical  path  may  be-  something 
quite  different  than  we  expect  if  the  accuracy  of  tune  estimates  is  not 
taken  into  account. 

Time  Tv  in > ate s 

The  most  difficult  characteristic  to  define  for  any  activity  is  the 
expected  duration  to  complete  it.  This  time  estimate  will  set  the 
benchmark  that  schedule  performance  is  measured  against,  but  that  perfor¬ 
mance  track  record  for  both  industry  and  government  is  far  from  good. 
There  seems  to  be  a  constant  interaction  between  the  expectations  and 
inter  pretations  of  the  asker  and  the  doer  when  we  develop  time  estimates. 
The  nature  of  that  interaction  is  not  very  well  understood  in  many  cases. 
Referem  e  1,  page  78,  gives  a  humorous  account  of  the  interaction  between 
an  iridiv  dual  and  the  boss  during  the  negotiating  of  a  "reasonable"  duration 
for  a  production  run.  Both  are  participating  in  a  gaming  process  where  each 
is  trying  to  anticipate  the  other's  logic  and  expectations  with  the  result 
being  a  little  dubious  to  both. 

One  of  the  first  appproacfies  to  improve  estimates  is  to  break  an 
activity  down  into  greater  detail  and  estimate  smaller  pieces  of  it.  That  is 
the  basil  rationale  for  the  network  approach  because  it  allows  us  to  add 
many  smaller  activities  to  give  an  expected  duration  for  a  single  overall 
task.  But*  we  are  still  fared  with  the  problem  of  estimating  accuracy  for 
the  lowest  level  u<  tivity.  The  next  technique  to  improve  accuracy  is  to  use 
multiple  estimates  for  each  activity. 


4-5 


The  «  Iforts  tl  at  we  normally  deal  with  in  acquisition  scheduling  are  not 
always  well  defmtd  and  frequently  have  not  been  done  before,  at  least  not 
in  the  way  that  is  required  for  a  particular  program.  If  the  product  is  not 
new  in  some  way,  .hen  we  would  not  be  given  the  job.  This  means  there  is  a 
degree  of  uncertainty  involved  and  the  time  estimates  should  take  that  into 
account.  The  use  of  several  time  estimates  that  are  combined  through  some 
weighting  scheme  is  a  good  approach  and  PERT  employs  such  a  technique. 
We  will  discuss  the  merits  of  the  PERT  technique  in  Chapter  8  in  some 
detail  and  offer  an  alternate  scheme  to  deal  with  uncertainty  in  a 
quantitative  way.  At  this  point  we  will  only  look  at  the  PERT  scheme, 
which  is  used  widely  in  our  business. 

The  objective  of  the  estimating  process  is  to  arrive  at  the  length  of 
time  for  an  activity  that  is  the  best  representation  of  the  range  of  possible 
circumstances  th.it  may  occur.  We  will  leave  the  statistical  details  for 
Chapter  8,  but  tin  "expected  time"  is  the  characteristic  that  best  describes 
an  activity  for  purposes  of  network  analysis.  This  is  the  mathematical 
approximation  of  a  50%  total  probability  of  occurrence  or  a  weighted 
average  time. 

In  PERT  the  expected  time  is  derived  from  three  time  estimates  for  a 
singly  activity,  these  are: 

1.  most  optimistic  time  (a) 

2.  most  likely  time  (m) 

3.  most  pessimistic  time  (b) 

The  most  optimistic  time  estimate  is  about  the  shortest  possible 
duration  for  the  activity  assuming  that  everything  required  happens  in  the 
most  time  efficient  manner.  Again,  see  Chapter  8  for  the  statistical 
assumptions,  but  t his  represents  about  a  1  in  100  chance  of  occurring.  There 
is  also  no  assumption  of  unusual  external  influences  or  interference  from  the 
results  of  any  other  task. 

The  most  likely  time  estimate  represents  the  duration  that  would  occur 
most  often  for  a  repetitive  activity  or  has  the  greatest  chance  of  occurring 
for  a  one-time  activity.  This  is  not  necessarily  the  same  as  the  50% 
cumulative  probability  point,  hence  the  need  for  this  treatment. 

The  most  pessimistic  estimate  is  at  the  far  end  of  the  range  of 
possibilities  and  iias  about  a  1  in  100  chance  of  being  exceeded.  Again, 
there  is  no  assumption  of  unusual  external  influences  (acts  of  God,  strikes, 
etc.)  and  it  should  not  take  into  account  the  outcome  of  any  other  task. 
Each  activity  must  be  estimated  as  a  stand-alone  entity  from  the  network 
(statistical  independence). 

The  expectec  time  (Te)  is  then  given  by  the  following  formula: 


Tins  approximates  a  cumulative  3  probability  of  completing  the  activity 
in  that  nine  or  less.  The  formula  wa*  derived  by  the  developers  of  PERT 
and  is  a  sirnpli fieri  form  of  a  more  <  omplex  relationship. 


The  expec  ted  time  estimate  is  the  value  that  should  be  used  for  the 
network  calculations,  but  remember  it  is  an  average  duration  that  should 
give  a  ‘>0/30  chance  of  accomplishment  on  or  before  that  point  in  time. 
There  are  useful  techniques  for  developing  confidence  intervals  for  network 
points  that  will  answer  questions  such  as:  "At  what  point  in  time  will  we 
have  a  /3%  or  90%  chance  of  completion  based  on  the  estimates?'  We  will 
present  these  techniques  in  Chapter  8. 

The  important  concept  here  is  to  use  some  consistent  and  logical 
scheme  to  integrate  multiple  time  estimates  for  each  activity  in  the 
network.  These  multiple  estimates  can  come  from  the  same  source  or 
multiple  sources  but  you  will  find  that  most  estimates  will  be  derived  from 
question  and  answer  sessions  with  program  office  and  contractor  personnel. 


Strengths 


Network  schedules  give  us  the  logic  and  organizational  structure  to 
combine  many  activities  and  incor  >orate  the  complexity  of  the  relationships 
between  tasks.  This  lets  us  gatht  r  schedule  information  from  all  available 
sources  within  a  program  and  then  integrate  that  data  in  a  graphical  form 
that  clearly  shows  what  we  know  about  the  evay  the  program  will  be 
executed.  At  the  same  time  t  le  process  of  building  the  network  will 
highligh  what  we  don't  know  and  give  us  the  chance  to  fill  in  the  gaps  where 
possible. 

A  network  is  ideal  for  the  planning  phases  of  a  program  when  there  is 
still  some  flexibility  in  the  time-phasing  of  activities.  A  good  network 
analysis  of  a  program  sets  a  firm  foundation  for  getting  things  moving  in  an 
orderly  ashion  when  the  go-ahead  is  received  for  a  project.  If  this  initial 
effort  is  tied  in  with  an  organizing  scheme  such  as  the  Responsibility 
Assignment  Matrix,  discussed  in  Chapter  3,  products  from  the  network 
schedule  can  be  extracted  either  by  responsible  organization  or  the  WBS 
items.  We  can  thus  provide  sub  schedules  for  the  effcrt  that  a  program 
participant  must  accomplish  over  a  period  of  time  (this  could  be  a  simple 
milestone  chart  or  a  network  in  itself).  These  products  are  well  suited  to 
documents  such  as  the  Program  Management  Plan  (PMP).  AFR  800-2  states 
that  the  PMP  is  directive  on  program  participants! 

A  network  schedule  can  be  developed  at  any  level  of  detail  and  the 
more  detail  we  can  incorporate  the  greater  the  accuracy  of  the  schedule 
predictions.  No  one  will  argue  much  with  a  very  generalized  schedule  of  the 
program,  but  as  soon  as  we  start  showing  the  level  of  detail  that  explicitly 
defines  the  interactions  between  groups  for  specific  tasks  there  will  be 
plenty  of  ‘feedback.  Some  of  the  exchanges  may  be  emotional  as  an 
indivulu.il  feels  his  area  of  responsibility  is  being  encroached,  but  they  will 
be  ex<  lu.nges  of  information.  That  is  the  objective  in  the  first  place! 


Network  analysis  can  be  used  at  any  phase  during  a  program's  life  cycle, 
but  the  objective  and  the  use  of  results  will  vary.  An  analysis  performed 
during  the  Full  Scale  Engineering  Development  phase  may  indicate  that  we 
have  a  low  confidence  of  meeting  the  directed  date  for  an  Initial  Opera¬ 
tional  Capability  (IOC).  That  may  be  a  very  unpopular  result,  since  most 
program  parameters  are  already  set  (especially  the  budgets).  But  this  type 
ot  analysis  can  give  ideas  of  where  to  concentrate  on  improving  schedule 
performance.  It  may  also  show  us  that  current  plans  cannot  be  accom¬ 
plished  and  should  be  changed! 

Weaknesses 

There  have  been  strong  arguments  voiced  against  the  use  of  large 
network  schedules  as  a  management  control  technique.  These  criticisms 
have  centered  on  the  PERT  and  CPM  approaches,  but  apply  to  networking  in 
general.  Once  an  effort  is  underway  a  large  network  can  become  unwieldy 
to  maintain  as  plans  inevitably  change.  PERT-type  efforts  to  control  entire 
programs  or  contracts  within  a  program  can  collapse  of  their  own  weight. 
The  result  may  be  a  monthly  report  that  is  simply  a  minor  rehash  of  the 
initial  plan  and  not  descriptive  of  the  current  situation.  With  networks 
bigger  is  rarely  better. 

A  network  is  an  approach  for  setting  up  a  management  information 
system.  There  are  other  ways  of  fulfilling  the  information  needs  of  project 
management  (i.e.  planning,  organizing,  directing,  and  controlling),  but  no 
approach  will  work  unless  we  properly  scope  the  amount  of  effort  needed  to 
support  it  and  make  a  conscious  decision  to  commit  those  resources.  A 
network-based  system  can  require  a  relatively  large  amount  of  time  to  setup 
and  maintain,  although  the  degree  of  the  application  can  be  tailored  by  the 
level  of  detail  incorporated  (and  that  is  our  suggested  approach). 

If  there  is  not  a  clear  commitment  by  upper  level  management  (SPO 
Director  and  Division  Chiefs)  to  implement  and  use  a  network  system  it  will 
not  be  a  medium  of  information  exchange.  The  management  style  of  an 
organization  is  chosen  by  the  boss,  either  explicitly  or  implicitly.  It  soon 
becomes  obvious  to  the  members  of  an  organization  what  information  the 
boss  thinks  is  important  and  this  is  where  the  real  effort  is  focused. 

Computer  based  network  systems  are  the  next  area  ol  problems.  Large 
network  applications  are  normally  automated  to  some  extent  since  the 
amount  of  data  being  maintained  is  extensive.  Most  contractor  developed 
schedules  are  some  form  of  automated  network.  Although  there  are  efforts 
in  process  to  provide  this  type  of  computer  support  to  our  program  offices, 
the  access  to  these  resources  is  limited  at  this  point,  so  we  have  a  very 
limited  ability  to  handle  large-scale  networks  internally. 

The  PERT  and  CPM  systems  have  also  been  criticized  for  their 
tendency  to. focus  attention  on  the  critical  path  only.  In  Chapter  8  we  will 
show  the  mathematical  detail,  but  there  can  be  a  considerable  amount  of 
"optimistic  bias"  in  the  expected  time  predicted  by  the  single  critical  path 
calculations.  We  can  get  a  general  idea  ol  the  extent  of  the  problem  for  any 
application  by  identifying  the  number  of  alternate  paths  through  the 
network  that  are  close  in  total  length  to  the  critical  path  Cay  within  a  few 
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%).  The  slack  time  will  be  low  on  these  paths.  11  there  are  multiple  paths 
close  to  the  critical  path  length,  then  the  expected  time  will  be  optimistic 
to  some  extent  and  a  more  complex  method  should  be  used. 
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Chapter  Five 
L  INC  OF  BALANCE 

Introduction 

The  line  ot  balance  technique  is  a  special  application  of  networking 
that  is  used  for  many  repetitions  of  a  set  of  activities,  such  as  on  a 
production  effort.  It  is  a  good  mechanism  to  provide  overall  schedule  status 
information  for  a  large  project  and  will  pinpoint  problem  areas  for  a  more 
detailed  analysis.  A  line  of  balance  system  is  not  typically  developed  or 
maintained  by  a  program  office,  but  they  are  employed  b>  contractors  on 
many  of  our  systems. 

Description 

The  basic  idea  for  the  line  of  balance  is  to  time  phase  a  large  number 
of  identical  networks  by  setting  the  planned  completion  date  for  each  one 
and  then  backing  up  the  events  that  comprise  it  to  find  when  they  must  be 
accomplish  *d  to  meet  the  planned  dote.  Since  each  network  is  identical  (as 
with  manufacturing  operations)  we  <  an  find  out  how  many  of  each  type  of 
event  must  occur  at  any  point  in  time  to  met  the  objectives. 

The  line  of  balance  consists  primarily  of  three  components;  the 
objective,  the  program  and  the  progress  chart.  It  is  the  particular  line  on 
the  progress  chart .  that  gives  this  technique  the  name  "Line  of  Balance." 
Contractor  reports1  will  contain  the  actual  graphics  portraying  these  three 
components,  and  we  will  look  at  how  each  is  constructed  to  make  this 
product  useful  to  the  program  office. 

The  first  component  of  the  line  of  balance  system  is  the  objective 
which  is  a  graphic  display  of  the  cumulative  end  item  delivery  forecasted 
(typically  what  is  called  for  in  the  contract).  The  actual  experience  to  date 
would  also  be  shown.  For  the  example,  shown  in  Figure  12  (stolen  from  our 
sister  service, reference  1),  the  contract  called  for  30  units  to  be  delivered 
by  the  end  of  April.  Only  14  have  been  delivered.  Using  the  fingers  and 
toes  of  you  and  your  neighbor,  you  can  easily  see  that  delivery  is  falling 
behind  by  16. 

The  second  component  is  the  program.  This  is  a  flow  diagram 
representing  established  events  (control  points)  for  the  process.  These 
points  are  the  key  material,  component,  fabrication  or  assembly  points 
necessary  to  deliver  the  end  item.  The  lead  times  for  these  points  are 
shown  graphically  on  the  chart  or  against  the  scale  on  the  bottom.  What  are 


The  Air  Force  Data  item  for  this  is  a  Production  Analysis  Report,  DI- 
P3455/P- 109- 1;  the  Army  has  used  Dl-P-1607,  Line  of  Balance  Reports;  the 
Navy  has  used  UDL-A-23001,  Chart,  Line  of  Balance. 
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the  »  riteria  lor  a  point  to  be  designated  "key"?  First,  the  point  should 
represent  a  measurable  progress  toward  completion  of  the  item,  and  second 
it  should  be  a  potential  hang-up  or  bottleneck  for  the  process  that  can  be 
isolated  for  management  control.  The  program  or  lead  time  diagram  shown 
in  Figure  12  represents  the  points  t fiat  one  unit  goes  through  from  start  to 
stop.  Hie  scale  is  usually  in  work  days;  therefore  initial  purchasing  must 
begin  2u  work  days  before  end  item  delivery.  All  other  things  being  equal,  a 
1  day  slip  here  would  slip  the  ship  date  by  1  day. 

The  third  component  is  the  progress  chart.  This  chart  shows  the  status 
at  each  of  the  control  points.  In  our  example,  the  n  imbers  1-12  along  the 
horizontal  axis  refer  to  the  checkpoints  1-12  on  the  program  chart.  The 
scale  along  the-  vertical  axis  is  the  number  of  units.  The  scale  reflects  units 
0-80  because  that  is  what  the  contract  calls  for— delivery  of  80  units.  So  far 
we  can  see  that  60  units  have  passed  through  check  point  1,  45  through 
checkpoint  2,  49  thr  ough  checkpoint  3,...,  and  14  have  neen  shipped. 

And  now  we  get  to  the  line  of  balance  itself.  The  line  of  balance  is  an 
actual  line  drawn  on  the  progress  chart.  This  line  .hows  how  many  units 
should  have  pushed  through  a  given  point  by  a  certain  date.  Examining  the 
line  of  balance  drawn  in  the  example  we  note  the  diiferences  between  the 
line  and  the  status  shown  by  the  vertical  bars.  The>e  differences  reflect 
situations  ahead  or  behind  schedule  at  the  given  points.  For  example,  note 
that  activity  is  ahead  of  schedule  at  points  1,  4,  6,  an<  9.  Activity  is  behind 
schedule  at  all  other  points. 

The  line  of  balance  itself  is  constructed  from  information  on  the 
objective,  the  program  and  the  progress  chart.  The  line  is  different  for  each 
point  and  is  calculated  as  follows.  For  example,  let's  compute  the  line  of 
balance  at  point  7.  Say  today  is  1  May,  how  many  in;  uts  should  be  at  point 
number  7?  Since  the  lead  time  for  this  point  is  12  work  days  (from  the 
program),  we  should  check  how  many  units  are  required  at  "ship"  on  16  May 
(12  workdays  hence).  Looking  at  the  objective  chait,  we  notice  that  the 
schedule  calls  for  41  units  to  be  shipped  on  16  May.  Therefore,  12  days 
earlier,  i.e.,  on  1  May,  we  need  41  units  through  checkpoint  7.  Since  there 
are  oi  ly  19  units  we  conclude  we  have  troubles. 

Strengths  and  Weaknesses 


The  line  of  balance  technique  is  a  special  application  of  networking  so 
it  shares  most  of  the  strong  and  weak  points.  However,  this  method  is  not 
as  difficult  to  maintain  as  a  full  network  would  be  for  a  large  production 
effort.  The  tiering  of  many  smaller  networks  is  a  much  easier  operation, 
especially  for  computer  applications.  It  also  condenses  the  presentation  of 
current  status  to  only  flag  significant  problems.  On  the  other  hand,  it  will 
not  isolate  the  part  of  an  operation  leading  to  a  check  point  that  is  causing  a 
behind  schedule  condition.  The  manager  still  has  to  ferret  out  that 
information. 
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F  sample 

Figure  13  is  an  example  of  a  contractor  prepared  line  ol  balance 
report  from  the  TIPI  Program  Office  here  at  USD.  The  program  part  of  the 
<  hart  has  a  maximum  lead  time  of  18  months  for  each  unit  delivered.  The 
contract  (alls  for  IS  units  to  be  delivered  by  April  of  1980,  and  each  unit 
has  XI  checkpoints  or  major  milestones  to  complete.  The  line  of  balance  at 
the  "as  of"  date  s  iows  a  combination  of  checkpoints  ahead  of  and  behind 
schedule. 

A  number  o!  points  are  complete  for  all  18  units,  while  there  are 
problems  indicated  at  8,  I  f,  lb,  17,  18,  25,  30,  31,  32,  35,  36,  38,  40,  41,  42. 
In  this  case  there  was  much  dialogue  between  the  SPO  and  the  contractor  on 
problem  at  eas. 


Chapter  Five  References 

I.  Je<  hmques  for  Work  Scheduling,  Army  Management  Engineering  Training 
Activity  (AM E TAT,  course  handout,  Rock  Island  Arsenal,  Ill. 
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Figure  13 


Chapter  Six 

MASTF.R  INTEGRATED  PROGRAM  SCHEDULE 


Introduction 

In  the  previous  chapters  we  have  covered  the  major  scheduling 
techniques  that  will  be  encountered  within  a  Program  Office.  We  have  also 
focused  on  the  need  to  schedule  program  activities  in  a  way  that  clearly 
shows  the  dependencies  or  constraints  between  them  while  using  a  structure 
that  allows  us  to  track  directly  to  the  definition  of  the  total  job  to  be  done 
(the  Program  Work  breakdown  Structure)  and  the  organizations  responsible 
for  getting,  it  done.  The  experience  here  at  ESD  has  shown  that  the  most 
difficult  part  of  the  planning  and  scheduling  process  for  a  program  is 
defining  and  relating  the  many  tasks  that  the  program  office  and  other 
government  people  must  accomplish.  We  are  much  more  adept  at  laying  out 
what  our  c  ontractors  must  do.  That  is  why  we  stress  the  term  program  as 
more  inclusive  than  contract  in  the  WBS  and  Master  Schedule. 

In  this  chapter  we  will  present  one  very  usable  approach  to  developing 
a  Master  Integrated  Program  Schedule  (MIPS)  based  on  techniques  that  have 
been  successful  in  one  ESD  program  (SACD1N-ESD/DC V).  This  approach  is 
based  on  a  mechanism  for  networking  coupled  with  a  procedure  for  pulling 
together  all  of  the  expert  information  needed  to  construct  it.  The  next 
chapter  will  show  a  practical  way  to  maintain  and  report  information  from 
this  network  through  a  milestone  schedule  system. 

Definition 

The  term  "Master  Integrated  Schedule"  is  frequently  found  throughout 
weapon  system  acquisition  literature.  Adopting  a  definition  from  Major 
John  Douglass  (reference  1:  "Development  of  an  Integrated  Master 
Schedule"),  an  MIPS  is: 

...  a  detailed  program  schedule  which  portrays  all  of  the 
major  elements  of  a  program  and  all  related  development  efforts 
in  such  a  manner  that  the  interrelationships  are  easily  seen.  The 
schedule  is  updated  regularly  and  is  recognized  by  all  program 
personnel  as  the  only  schedule  authorized  for  publication  outside 
the  program.  The  schedule  is  reviewed  and  validated  at  least 
monthly  by  the  program  manager. 

Adding  to  that  definition,  the  MIPS  represents  the  Program  Baseline 
Schedule.  It  is  a  schedule  prepared  by  the  program  office  to  address  the 
interrelation  and  interactions  of  all  government  and  contractor  organi¬ 
zations  in  the  support  of  the  program.  It  is  not  a  contractor  prepared  data 
item. 


Back gi , uind 

Although  the  term  "Master  Si  heduie”  is  freq  entlv  heard,  a  product 
which  resembles  the  above  definition  has  been  Kicking  in  many  ESD  SPOs. 
This  .  ^inclusion  is  supported  by  past  staff  assistance  visits.  Based  upon 
findings  of  the  flq  AFSC  Program  Management  Assistance  Group  (PMAG), 
the  same  situation  exists  throughout  essentially  all  sPOs  within  AFSC.  To 
date,  most  SPOs,  have  not  developed  (or  have  not  I  een  able  to  develop)  a 
Master  Integrated  Program  Schedule. 

Instead  of  a  MIPS  the  typical  scheduling  ml  irmation  within  a  SPO 
consists  of: 


a.  A  single  viewgraph  used  lor  the  Command  Assessment 
llevtcw  or  in-house  briefing  which  depicts  the  ovt  rail  program  schedule. 
This  is  frequently  referenced  as  the  baseline  or  master  integrated  schedule 
but  it  only  depicts  10  lines  of  top  level  schedule  information. 

b.  Contractor  data  items.  These  c  ome  in  all  shapes  and  sizes. 

Some  ire  good,  but  even  the  best  generally  only  a  Idress  the  contractor’s 

at  tions.  They  generally  do  not  adequately  cover  the  actions  and  inter- 

a<  tions  of  the  many  other  agencies  (including  the  SIM)  which  are  key  to  the 

total  program  schedule. 

c.  An  assortment  of  schedules  in  the  Program  Management  Plan 
(PMP),  Test  and  Evaluation  Master  Plan  (TEMP),  Integrated  Logistic. 
Support  Plan  (ILSP),  MO  As,  and  many  other  plans  which  are  frequently 
inconsistent  with  each  other  and  generally  fail  to  co  er  all  critical  program 
actions. 

None  of  the  above  available  scheduling  information  items  by  them¬ 
selves  represents  a  MIPS.  After  numerous  interviews  throughout  ESD,  we 
believe  that  the  reason  for  a  lack  of  a  MIPS  within  our  SPOs  is  due  to  the 
lack  of  an  easily  usable  and  responsive  technique  for  developing  and 
maintaining  it.  Our  people  know  how  to  plan  their  individual  disciplines 
well.  It  is  frequently  the  physical  work  which  causes  any  inter-disciplinary 
planning  effort  to  be  abandoned  or  causes  a  desperate  and  normally 
unsuccessful  turn  to  automation  for  help. 

Anyone  who  has  tried  to  build  a  network  of  any  complexity  recognizes 
the  immense  amount  of  work  required  to  draw  (and  redraw  and  redraw)  a 
network  until  an  acceptable  product  is  developed.  When  we  consider  that  a 
MIPS  for  a  major  program  can  require  200-400  events,  it  is  easy  to  see  why 
most  manual  attempts  have  failed. 

The  failure  of  manual  attempts  has  frequently  made  SPOs  turn  to 
either  automation  or  to  outside  contractors  (or  both)  for  assistance  in 
developing  a  MIPS.  To  date,  results  of  their  efforts  have  received  mixed 
leviews.  *There  has  been  no  sustained  use  of  any  single  automated 
scheduling  networking  technique  at  ESD.  Automated  efforts  tend  to 
produce  large  amounts  of  schedule  data  which  can  be  useless  unless  someone 
ran  analyze  the  information.  Obviously,  the  computer  is  no  panacea. 


6-2 


Out  ado  contractors  aro  also  riot  tin*  complete  solution.  We  frequently 
assume*  tlial  our  inability  to  develop  i  Mil’S  is  due  to  a  lack  of  internal 
talent  arm  attempt  to  remedy  this  by  outside  expertise.  Over-reliance  on  a 
c  ontrai  tor  c  an  also  lead  ta  problems  nice  the*  information  must  still  c  ome 
from  and  be  understood  by  the  program  office  people. 

Objectives 

This  approar  b  builds  on  the  study  performed  by  Major  Hi  uglass  (refer¬ 
ence  1)  which  discusses  the  problems  of  developing  a  Master  Sc  hedule  within 
a  Sl’O  and  oilers  excellent,  real- world  advice  base  d  on  numerous  PMAG 
experiences  and  observations.  The  objective  is  to  piovide  an  effective  and 
simple  to  use  technique  for  developing  a  MIPS  that: 

a.  Minimizes  the  need  tor  extra  training. 

b.  nistnbutes  the  schedule  workload  evenly  throughout  trie  SPO. 
This  maximizes  the  involvement  ol  all  divisions  and  their  functional 
disc  iplines  in  the  MIPS  development  process. 

c  .  tlmphasiz.es  the  actions  and  interac  tions  of  all  government  and 
c  oru  racier  organizations. 

d.  Supports  numerous  "what  if"  exercises  and  allows  for  easy 
assessment  ol  schedule  impact  based  on  budget  changes. 

e.  Supports  internal  workload  planning,  recognizing  that  staff  and 
program  res'  urces  have  limited  flexibility  and  that  worklocd  planning  is 
essential. 


f.  Develops  "the"  master  integrated  schedule.  The  MIPS  serves  as 
the  baseline  for  the  planning  of  many  organizations.  A  single  recognized 
MIPS  is  essential  for  the  efficient  and  integrated  planning  of  effort  by  these 
organizations. 

g.  Enhances  communications  on  schedule  issues  and  which  can  serve 
as  a  diagnostic  aid  to  schedule  problems. 

h.  Can  identify  schedule  problems  early  and  can  reduce  the  drain  on 
SPO  resources  created  by  "fire  fighting." 


FLEXIBLE  NETWORKING 


Definition 


The  flexible  network  is  a  tool  for  providing  the  entire  SPO  with  a 
visible  and  easily  understood  picture  of  the  total  program  schedule.  It 
<  onsists  of  a  network  of  events  posted  on  a  large  wall  surface  or  on  boards 
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ul  lived  i.  w.dls.  I  Im.*  events  arc  <  onne<  ted  to  dcpi<  t  mterdepi  ndench  s. 
Hey  to  1 1 1<  sin  css  ol  the  flexible  network  is  the  case  of  preparing  and  mbre 
important  v  the  case  ol  >  hanging  the  network. 

I  ’l  OCedlir  I  > 

I’o  o  * vc i  >p  a  flexible  network  requires  certain  materials: 

a.  A  ri  >m  in  whu  h  you  can  post  a  network  on  the  wall.  The  network 
size  shout  I  be  lt>  ft  long  by  4  ft  high.  A  longer  area  is  desirable  and  the 
technique  wil  work  with  only  an  8  ft  surface.  An  easily  accessible 
conlereiK  •  rm  n  is  ideal. 

b.  I  he  wall  surface  should  be  covered  with  a  cork  type  surface. 
Horneosoi  •  bo  irds  (V  x  8')  with  a  gray  surface  can  be  obtained  from  base 
supply  1 1 .  time  Is.  However,  a  cork  surface  obtained  through  local  purchase 
makes  a  >ett<  •  looking  display.  Mounting  the  boards  is  a  great  self-help 
project. 

c.  Small  (2h  in.  by  Hi  in.)  <  olored  cards  are  used  to  identify  each 
event.  Oiffeient  colors  are  used  to  indicate  that  the  event  is  the 
responsibility  of  a  particular  agency  (SPO,  contractor,  AFTEC,  AFCC,  etc.). 

d.  Map  tacks  (the  type  with  the  spherical  head)  are  used  to  post  the 
event  cards  to  the  cork  board. 

e.  Him  k  elastic  thread,  available  at  your  friendly  sewing  supply 
store,  is  used  to  connect  the  events.  The  elastic  thread  is  tied  from  one 
tack  to  another  to  depict  interdependencies. 

The  abo\e  materials  take  a  bit  of  effort  to  assemble,  but  the  labor 
they  save  in  the  long  run  is  many  times  the  original  effort  to  get  started. 

With  materials  in  hand,  you  are  ready  to  start  developing  a  network. 

Me  j >  K  Form  an  MIPS  team  within  the  SPO.  Business  Management 
representation  on  the  team  is  essential  since  that  division  will  have  the 
ultimate  responsibility  for  maintenance  of  the  network.  However,  the  team 
should  be  chaired  by  the  most  qualified  "planner"  within  the  team.  The  ideal 
chairman  is  someone  who  has  been  assigned  to  the  SPO  for  at  least  two 
years  and  who  has  a  solid  working  knowledge  of  the  total  program.  He  or 
she  may  <  omr  from  any  division,  but  the  knowledge  ideally  would  be  in  more 
than  one  lun<  t  onal  area. 

The  team  is  filled  by  four  or  five  other  people  from  other  functional 
divisions.  Tlu  best  candidates  are  not  necessarily  the  most  experienced 
ones.  Instead,  aggressive  and  imaginative  people  should  be  chosen. 


1 1 us  MIPS  project  is  an  opportunity  lor  providing  some  of  the  SPO 
entry  level  people  with  a  good  insight  into  the  other  SPO  disciplines;  an 
insight  that  local  training  course:  <  annot  reproduce.  The  team  will  be 
requiri  I  on  a  lull  time  basis  tor  the  lirst  two  weeks  and  on  a  half-time  basis 
for  the  following  two  weeks.  This  is  a  significant  amount  of  work;  however, 
t he  alternative  is  to  continue  expending  all  SPO  resources  without  a  definite 
plan.  1'he  team  should  be  formally  chartered  by  the  System  Program 
Hirec  tor  (SPD)  with  a  license  to  ask  questions  and  require  responses. 

Step  2.  Review  other  MIPS  efforts.  Contact  another  SPO  that  has 
condu.  ted  the  same  exercise  and  make  an  appointment  to  .new  their  flexible 
netwoik.  At  this  time,  networks  ate  available  at  the  S/ CDIN  SPO  and  at 
the  l  )A  SPO  business  Managment  Divisions.  Seeing  <.  n  actual  network 
makes  it  easier  to  bring  the  team  up  to  speed  and  is  a  good  investment  of  an 
hour  oi  two. 

Step  3.  Determine  the  scope  of  the  network.  The  network  can  be 
built  tor  a  single  project  within  a  basket  SPO,  for  a  single  major  program,  or 
for  a  number  of  small  related  projects  which  have  significant  numbers  of 
interdependent  les.  It  is  not  applicable  to  building  a  network  of  projects 
which  are  unrelated  except  by  their  technology  or  their  assignment  to  the 
same  program  office. 

Step  k.  Gather  data.  The  initial  set  of  data  should  be  gathered  from 
written  sources.  These  include: 

a.  DC P,  PMD,  AFSC  Form  56  and  other  progra  n  direction. 

b.  PMP,  TEMP,  ILSP,  CRISP  or  any  other  SPO  plan  which  exists. 
Draft  plans  are  adequate  for  this  purpose. 

c.  Contract(s)  delivery  schedule(s),  this  schedule  is  contained  in 
Section  H  of  the  contract. 

d.  Contractor  action  si  hedule.  This  is  a  d.  ta  item  available 
within  business  Managment  and  in  most  divisions.  Some  contractors  deliver 
both  schedules  and  networks.  Both  are  useful  sources  of  data. 

e.  Contract  GFE  schedule.  This  is  usually  an  attachment  to  the 
contra*. t.  Ask  your  PCO  for  it. 

f.  Any  other  source  of  either  schedule  or  pla  ining  information. 
Note  that  useful  information  is  not  limited  to  informat  on  that  indicates 
both  an  event  and  a  time.  If  a  Test  and  Evaluation  M.  ster  Plan  (TEMP) 
indicates  that  Initial  Operational  Test  and  Evaluation  (IOT&E)  will  be 
condui  led  and  that  a  Logistics  Supportability  Plan  will  b  ■  written-but  fails 
to  sa>  .vhen,  this  is  still  useful  information.  It  will  support  the  obvious 
question,  "We  plan  to  do  this,  when  and  who  plans  to  do  it?"  Memoranda  of 
Agreement  are  also  good  sources  of  data.  They  f  equently  require 
signif H  .mt  actions  such  as  the  provision  of  test  resoi  rces  without  any 
refer<  n<  ed  schedule.  The  scheduling  of  these  resources  i:  a  key  element  of 
the  Mil’s  development. 
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Step  *>.  Develop  initial  nctvvorf.  Havmp  assembled  your  materials, 
your  team  and  your  data,  you  are  filially  ready  to  start.  Divide  up  the  work 
surface  into  time  periods.  You  may  want  to  expand  the  s<  ale  for  the  first 
year  to  provide  ample  space.  I  ;,.e  the  map  tacks  and  the  black  elastic 
thread  to  make  vertical  lines  dividing  the  board.  If  you  decide  to  change  the 
time  scale,  you  will  only  have  to  im.ve  the  tacks. 

Fill  out  the  action  cards  like  this: 


liven t  Description  No.  32 

Purchase  Request  (l'R)  package 
assembled  for  external  coord. 

WBS  Interface:  5.2. 1.3 

OPR  Schedule  Date 

DC  VX  '6  Nov  SO 


Figure  l4/ 

The  cards  are  large  enough  so  that  use  of  any  uncommon  acronyms  can  be 
avoided.  The  network  is  supposed  to  answer  questions,  not  raise  them.  Use 
different  colored  cards  to  represent  the  SPO,  the  contractor,  procurement, 
and  any  other  agency  that  play  ,  a  major  role  in  the  program  (e.g.  AFCC  or 
AFLC).  Use  a  separate  color  to  identify  miscellaneous  organizations.  (An 
alphabetical  code  will  also  let  you  tie  in  to  a  Responsibility  Assignment 
Matrix  scheme,  reference  Chapter  3.) 

Using  the  source  data,  select  events  which  you  consider  significant. 
Do  not  waste  time  arguing  over  whether  an  event  is  signif it  ant.  If  you  wind 
up  with  too  many  low  level  events,  it  is  easy  to  remove  them  later.  Many 
seemingly  low  level  events  tend  to  be  critical  path  activities.  Source  coding 
of  system  spares  is  an  example  of  a  frequently  ignored  event  which  can 
significantly  impact  the  program.  A  delay  in  source  coding  can  delay  the 
development  of  Support  Equipment  such  as  Automatic  Test  Equipment  (ATE) 
which  in  turn  can  delay  Initial  Operational  Tests.  Make  a  point  not  to  argue 
over  what  is  a  significant  event  until  after  the  first  week.  What  you  should 
be  constantly  on  the  lookout  for  are  events  that  constrain  the  start  of 
activities. 

Do  not  duplicate  the  contractor's  action  schedule  in  total.  Select 
some  key  events  where  the  government  and  contractor  formally  interface 
(e.g.  providing  GFE,  accepting  delivery,  major  design  reviews,  major 
testing,  etc.).  Do  not  necessarily  select  the  contractor's  internal  milestones 
as  events  for  the  network  (e.g.  start  software  spec,  sunmit  Preliminary 
Design  Reviejv  agenda,  etc.).  Remember  that  your  objective  is  to  develop  a 
program  (not  contract)  network.  You  need  to  highlight  the  non-contractor 
actions  required  since  only  the  SPO  can  plan  these  actions. 
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hey  on  the  responsibilities  ol  outside  agencies.  These  ^re  our  major 
scheduling  problems.  It  is  the  planning  oi  the  work  ol  the  numerous  other 
agencies  involved  which  is  the  prim.iiy  objective  oi  tin-  MIPS  network. 

It  you  are  not  sure  when  to  st  hedule  an  event,  take  a  guess.  When  you 
are  not  sure  who  is  the  OPR,  take  another  guess.  11  you  are  wrong,  the  OPR 
will  be  quick  to  identify  it. 

At  first,  the  density  of  early  events  will  ne  quite  large.  Vie  often  have 
little  problem  in  identifying  the  fires  which  are  due  in  the  next  few  months. 
The  expanded  scale  for  the  first  year  of  the  network  should  alleviate  some 
of  the  overcrowding.  However,  if  the  network  becomes  overcrowded,  don't 
be  concerned.  You  can  c  lean  it  up  later.  Don't  be  concerned  with  eye 
appeal.  You  are  trying  to  make  a  master  plan  -  you  are  not  trying  to  make  a 
display  for  visiting  firemen. 

Step  6.  Identify  interdependencies.  Begin  w.'h  the  first  event  and 
consider  what  following  event  is  dependent  upon  sue  cessful  completion  of 
that  event.  Tie  the  black  elastic  sting  between  the  two  events.  You  will 
quickly  become  adept  at  tying  knots.  At  first,  some  events  will  seem  to  be 
totally  independent  from  others.  This  usually  indicates  that  other  signifi¬ 
cant  events  are  missing.  Most  program  event .  ate  interrelated.  The 
exceptions  (e.g.  Command  Assessment  Review,  Program  Financial  Reviews, 
and  Budget  Submissions)  are  generally  few.  The  f  inctional  areas  also  tend, 
at  first,  to  be  independent  of  other  areas.  This  independence  also  indicates 
that  some  events  are  missing.  Most  functional  ire  is  do  have  significant 
interactions  with  other  functional  areas. 

C  ontinue  the  process  of  identifying  interdependencies  until  you  have 
tried  to  connect  each  event  to  at  least  one  following  event.  Note  that 
certain  major  events  (e.g.  PMD  release)  may  be  necessary  prior  to  the  start 
of  numerous  other  events.  Try  to  depict  all  of  these  interdependencies. 

Step  7.  Identify  problem  areas.  Make  small  triangular  "flags"  out  of 
red  paper.  Pin  a  flag  to  any  event  for  which  a  problem  exists.  If  you  had  to 
guess  at  the  date  or  guess  at  the  OPR,  flag  tho  event  until  the  data  is 
confirmed  by  the  OPR.  If  your  written  source  data  provided  two  different 
dates  for  the  same  event  (a  common  occurence),  flag  the  event.  If  an  event 
occurs  too  late  to  support  a  following  event,  flag  it.  If  an  event  provides 
inadequate  lead  time  for  procurement  or  for  other  activities,  flag  it.  All 
lines  in  the  network  are  interpreted  to  flow  forward.  If  a  line  flows 
backward  due  to  incorrect  planning,  flag  the  line.  Events  which  need 
further  study  to  identify  interdependencies  also  should  be  flagged.  Try  to 
identify  as  many  potential  schedule  problems  as  possible.  The  intent  ol  the 
network  is  to  identify  these  problems  so  that  they  can  be  resolved. 

Step  8.  Conduct  initial  division  level  review.  Schedule  each  Division 
Chief  and.two  or  three  of  his  or  her  staff  for  a  two  or  three  hour  review  of 
the  network.  Schedule  the  divisions  in  series.  Idt  ntify  the  conventions  and 
explain  all  ol  the  events  to  the  Division  Chief.  Do  not  limit  the  review  to 
one  functional  area. 
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Seek  to  verily  the  information  lor  that  OPR  or  any  information  upon 
which  he  or  she  <  an  shed  light.  As  soon  as  further  information  is  provided, 
rnmediately  move  or  correct  the  event  if  the  change  is  small.  If  the  change 
s  major,  make  detailed  notes  to  support  making  the  corrections  later.  A 
major  benefit  of  the  flexible  netwotk  should  quickly  become  apparent.  It  is 
i-asy  to  make  even  major  changes  without  redrawing  the  entire  network.  A 
small  shift  of  an  event  can  be  made  without  even  retying  the  elastic  string. 

Attempt  to  resoh  rhe  flags  in  that  division's  functional  area.  If  you 

can't  resolve  the  division's  Hags,  make  a  suspense  for  solving  the  problem. 

Try  to  issue  one  day  suspenses.  Avoid  suspenses  in  excess  of  one  week. 
Many  ot  the  following  events  may  be  affected  by  the  flagged  event  and 
early  resolution  is  essential.  This  effort  should  be  the  number  one  priority 
within  the  SPO  at  this  time. 

After  verifying  your  initial  data,  ask  the  Division  Chief  to  identify 
events  which  should  be  added.  Do  not  be  surprised  if  little  information  is 
volunteered.  Some  people  do  not  like  to  post  their  plans  because  they  fear 
being  evaluated  against  that  plan,  or  for  other  reasons.  Others  will 

volunteer  a  host  of  data  which  may  be  significant  in  their  area,  but  which 

may  not  be  applicable  to  the  MIPS  network.  Try  to  limit  this  data  to  those 
areas  which  will  involve  interactions  between  functional  areas  or  between 
organize tions.  If  an  event  only  connects  to  events  within  that  division,  it  is 
not  a  likely  candidate  for  the  network.  It  is,  however,  an  excellent 
candidate  for  the  Lower  Level  or  Intermediate  Schedules  discussed  in  the 
next  chapter. 

After  this  set  of  questions,  ask  the  Division  Chief  to  identify  any 
events  which  should  be  added  for  other  divisons  or  organizations  to  support 
that  functional  area.  This  question  usually  leads  to  a  significant  outpouring 
of  useful  data.  While  people  may  hesitate  to  identify  their  plans,  they  are 
normally  quick  to  identify  the  support  they  need  from  others.  Remember 
that  each  Divison  Chief  will  have  his  chance  to  identify  this  type  of  data. 
This  methodology  has  proven  very  successful.  While  most  divisons  will 
quickly  identify  their  need  for  contracting  action,  only  the  PCO  will  be 
quick  to  identify  when  a  complete  contract  package  (e.g.  PR,  CCB 
Directive,  SOW,  etc)  must  be  provided  to  contracting  for  action.  The  PCO 
will  also  be  quick  to  identify  the  SPO,  contract  pricing,  JAG,  contract 
writing,  auditor  and  other  support  he  requires  to  complete  the  contract 
action.  The  MIPS  network  is  an  ideal  tool  for  procurement  planning. 

Alter  the  interview,  post  all  of  the  new  information  and  continue  with 
the  next  interview.  Interview  all  Division  Chiefs.  Interview  the  MITRE 
project  leader.  He  or  she  frequently  directs  more  resources  than  any  other 
Division  Chief  and  these  inputs  can  be  vital  to  the  scheduling  process. 
Include  the  PCO  and  your  liaison  officers  in  the  interviews.  Continue  the 
interviews  sequentially. 

Step  S.  Revise  the  network.  After  the  first  series  of  interviews,  the 
network  will  look  like  a  cluttered  spider's  web.  Try  to  clarify  the  network 
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by  eliminating  events  which  you  now  know  are  not  truly  significant. 
Rearrange  the  lines  to  eliminate  the  clutter.  Try  to  keep  functional  lines 
clear.  These  revisions  can  be  initiated  during  the  interview  process  when 
there  are  slack  periods.  Don't  postpone  these  updates. 

Step  10.  Staff  Review  (without  Program  Director).  Schedule  a  review 
of  the  entire  network  by  all  Division  Chiefs  without  the  SPD  in  attendance. 
Attempt  to  again  verify  data  and  to  resolve  flags.  Tins  is  the  last  chance  to 
provide  data  prior  to  the  SPD  review.  Stress  the.  fact  that  all  flagged  items 
will  be  briefed  to  the  SPD  who  will  in  turn  expect  briefings  on  the  Division 
Chief's  efforts  to  remove  the  flags. 

Step  I  1.  Review  the  MIPS  Network  with  the  SPD.  After  the  division 
level  review,  schedule  a  three  hour  review  with  the  SPD.  He  may 
recommend  major  changes  in  the  schedule.  If  he  does,  make  the  changes, 
and  repeat  steps  8  and  9  again.  After  you  successfully  review  the  network 
with  the  SPD  and  avoid  major  changes,  you  have  established  a  baseline 
sc  hedule.  Take  a  break.  Then  get  set  for  a  regular  series  of  reviews  and 
updates. 

Schedule  Maintenance 


Once  the  network  schedule  has  been  developed,  tracking,  controlling, 
and  updating  come  into  play.  Schedule  maintenance  will  continue  through¬ 
out  the  program.  It  is  a  dynamic  process  that  laps  many  sources  for 
information. 

Schedule  accomplishment  is  measured  by  more  than  the  passing  of 
calendar  dates.  Accomplishment  may  be  represented  by  milestone  events 
a<  cornplished,  percentages  of  tasks  completed,  and  by  expenditure  of 
resources.  The  most  obvious  measure  is  if  the  event  has  come  and  gone 
(e.g.,  the  request  for  proposal  is  on  the  street,  the  contract  has  been 
awarded,  the  first  article  has  been  delivered).  Accomplished  events  will  be 
reported  by  various  means  including  contractor  reports,  and  scuttlebutt. 
One  thing  is  certain:  You  will  miss  half  of  this  information  if  you  wait  for  it 
to  come  to  you.  You  have  to  stay  on  top  of  it.  Start  developing  your 
contacts  early. 

Another  aspect  you  should  be  aware  of  is  that  "schedules  ain't  what 
they  seem."  People  can  tell  you  that  an  activity  is  90%  complete,  but 
frequently  this  means  only  that  90%  of  the  allowed  time  has  passed.  A 
better  measure  would  be  that  9  of  10  meaningful  sub-milestones  have  been 
met.  You  will  have  to  develop  a  feel  for  what  is  "meaningful." 

Bec  ause  schedule  and  cost  go  together,  some  schedule  accomplishment 
is  measured  in  terms  of  cost.  In  contractor  cost/schedule  reports,  schedule 
varia  ice  may  be  quantified  by  comparisons  for  work  performed  (earned 
value)  and  work  planned.  If  the  performance  is  less  than  the  planned,  we 
have  ari  unfavorable  schedule  variance  measured  in  dollars.  This  is  but  one 
indicator  of  schedule  performance.  Whether  this  unfavorable  sign  is 
corroborated  by  other  schedule  data  will  remain  unknown  until  you  check 
the  other  lata. 
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liming  developed  the  schedule  (and  updated  it  as  necessary)  md 
having  <  stablished  a  satisiactory  maintenance  system,  the  next  stage  is  to 
crank  m  ways  to  predict  schedule  performance.  Trends  can  be  idmtified 
and  pi  ogress  can  lie  forecasted  at  an  extrapolateJ  rate.  Time  series  inalysis 
and  sc' m  parametric  equations  can  be  used  to  predict,  but  these  must  be 
temper. -d  by  risk  assessment.  It  is  a  good  idea  to  identify  the  key  risk  areas 
early  i  i  the  program.  For  example,  software  schedules  are  always  risky; 
contra*  t  award  estimates  are  usually  optimistic;  and  fab  ication  normally 
enroun.ers  a  delay.  You  will  need  to  know  how  much  "cushion"  you  have  in 
each  area  before  the  whole  program  has  to  slip!  Keep  in  mind  how  far  you 
have  come,  how  far  you  have  to  go,  and  what  pitfalls  you  might  encounter. 
We  wil  show  methods  for  dealing  with  these  questions  in  a  quantitative  way 
in  Chapter  8. 
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INTLil'1  ML.D1ATF  SCHliDf  ILFS 


Introdii'  ! !.  n 

At 'ci  the  Flexible  Networking  effort  is  completed,  the  second  phase 
of  a  .Vaster  Integrated  Program  Schedule  can  be  implemented.  As  we 
discussed  in  Chapter  3,  milestone  schedules  can  be  produced  as  an  output  of 
a  network-  schorl  do  to  address  limited  functional  (oriented  to  the  performing 
organization)  01  lower  level  WBS  aspects  of  the  program.  We  will  use  the 
term  "inter  medi  tie  schedules"  to  ide  ntify  this  type  of  output.  For  example, 
-m  intei  mi  diate  st  la  dole  might  depict  the  Tec  him  al  Order  (TO)  piotess  and 
identity  when  I  reliminary  1  Os  would  be  available,  when  verification  and 
validation  ■,  pin  med,  and  when  the  TO's  would  be  printed.  The  intermediate 
st  ledulf  should  be  limited  in  general  to  10-20  milestones  lor  a  particular 
In  et  ol  ihc  program. 

With  the  I  exible  netwoik  and  the  contractor's  schedules,  there  may  be 
some  question  ,s  to  the  need  for  "still  more  schedules."  However,  the 
intermedia te  sc  tedules  are  a  necessary  element  of  a  MIPS.  The  flexible 
net  wort  n.ualh  will  not  addresses  -.11  the  major  pro>  <-  an  events.  For 
example.  \  hile  be  network  inay  depu  t  when  .  key  piece  c  l  GFF  is  required 
br  the  <  ..iitract  r,  it  may  not  depict  when  it  will  be  ordered,  who  will  order 
it,  or  when  it  w  11  be  shipped.  These  events  are,  however,  critical  and  must 
lie  planne  d.  Th.s  is  the  role  of  the  intermediate  schedule.  Major  events 
Horn  tin  (lexitic  network  are  .selected  and  an  intei mediate  schedule  is 
developed  whit-'  identifies  how  the  netwoik  milestone  will  be  met.  But 
remember,  the  ctwork  is  still  the  official  baseline  schedule  and  the  single 
point  to  int  erpolate  and  distribute  changes. 

Schedule  [dements 

The  intermediate  schedule*  usually  cover  a  functional  area,  a  flow  of 
lo.istns  events  leading  lo  tlx  delivery  .  TO*,  u  flow  of  » on  figuration 
management  events  leading  to  Functmnal  and  Physical  Contigurat ion  Audits 
(FCrt/Pt  \),  a  flow  of  enbiiu*c.  f  leu  ding  to  the  vievelopmeiit  of  an 

external  interface,  or  other  s.mitar  functional  flows  are  ideal  candidates  for 
mtermt  tliate  sc  hedules. 

F^utside  X/aicms.  Intermediate  m  hedules  identity  when  a  functional  area 
require,  upport  from  another  age..t  .  The  TO  How  will  identity  a  support 
requirement  toi  printing  by  the  Air  Lugisti'  s  Center.  The  FCA/PCA  flow- 
will  inch  ate  a  requirement  for  maiiulacturing  suppoit.  The  engineering 
iruerl.f  e  f l^w  \  ill  mdit  at**  the  need  lor  an  Interface  Control  Drawing  vith 
another  agency.  The  interim-d'  ite  st  t-c  dole  not  only  identities  the  requited 
outsid-  agent  y  •upport,  it  alv>  idt  t  am  when  that  sup;  ml  i .  required.  This 
permits  the  p.nti<  ipating  and  ""[mg  apn  ici  t  >  <s  termini-  .f  the 
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requite  i!  support  cun  be  made  avail  able  to  support  the  current  plan. 
Intermediate  si  hc-dules  take  the  generalities  that  exist  in  MOA's  and  other 
agreements  and  c  onvert  them  into  specifics. 

The  intermediate  sc  hedule  is  an  ideal  way  for  insuring  that  outside 
suppot  t  t  equirements  are  c  learly  identified.  The  major  functional  sc  hedules 
can  he  made  a  standard  part  of  the  Program  Management  Plan  (PMP) 
through  the  Responsibility  Assignment  Matrix  approach  from  Chapter  3. 
The  total  book  of  intermediate  schedules  or  only  a  sele<  t  few  can  be  made  a 
reference  in  the  appropriate  MOA's.  Organizations  would  then  be  commit¬ 
ted  to  supporting  a  specific  program  schedule.  If  an  organization  has  a 
problem  witli  a  change  in  the  schedule  at  a  later  date,  they  have  the  chance 
to  identify  this  problem  during  the  update/coordination  cycle  of  the 
intermediate  sc  hedules.  The-  intermediate  schedule  oilers  a  solid  technique 
for  c  ommunic  atmg  detailed  sc  hedule  changes  to  supporting  organizations  so 
that  they  can  change  their  support  plans  accordingly.  A  key  benefit  of  this 
approach  is  the  identification  of  additional  interdependencies  between 
network  activities  as  outside  support  tasks  become  more  clearly  defined. 

Individual  R esponsibility.  The  intermediate  schedule  is  assigned  to  an 
individual  within  a  functional  area.  The  individual's  name  is  listed  on  the 
schedule  and  provides  an  easy  point  of  contact  to  outside  agencies. 
Responsibility  for  planning  and  monitoring  a  particular  facet  of  the  program 
is  assigned  down  to  the  level  that  the  actual  work  is  being  accomplished. 
This  has  an  added  benefit  of  improving  the  use  of  MITRE  resources.  Many 
SPOs  do  not  have  sufficient  visibility  into  their  MITRE  support  staff  which 
creates  a  barrier  to  effective  communication  and  limits  the  effectiveness  of 
the  MITRE  resources.  By  assigning  specific  schedules  to  individual  MITRE 
engineers,  this  problem  of  communications  is  avoided.  (The  actual 
assignment  is  done  by  the  MITRE  project  leader.) 

Problem  Tracking.  The  intermediate  schedule  also  offers  a  method  for 
insuring  that  fewer  of  our  problems  fall  through  the  cracks.  Frequently  a 
problem  is  identified  and  there  is  no  clear-c  ut  means  to  insure  that  the 
problem  is  resolved  and  not  forgotten.  By  using  the  intermediate  schedule, 
a  suspense  can  be  issued  to  a  SPO  Division  or  external  organization  to  add 
an  intermediate  schedule  which  specifically  addresse  and  solves  that 
problem. 


Identification  and  Assignment.  The  selection  of  events  or  areas  which 
require  an  intermediate  schedule  is  an  important  process.  Too  many 
schedules  will  overload  the  SPO's  limited  resources.  Too  few  will  result  in 
the  expenditure  of  resources  without  adequate  planning.  The  SPO  needs  to 
start  out  with  a  "reasonable"  number  of  intermediate  schedules  and  to 
gradually  grow  to  a  complete  set  of  schedules.  A  "reasonable"  number 
depends  upon  the  nature  of  the  program  and  upon  the  number  of  resources 
assigned*  to  the  program.  One  rule  of  thumb  is  to  determine  the  total 
number  of  professionals  assigned  to  the  SPO.  Include  liaison  officers,  staff 
support  (from  AC,  DE,  PK,  TOM,  TOI)  and  any  other  resources  either 
collocated  or  non-colJocated.  Include  your  MITRE  support.  It  is  reasonable 
to  e  xpect  that  every  professional  assigned  to  the  SPO  can  produce  and 
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maintain  one  or  two  intermediate  s<  h<  dules.  In  many  SPO's,  this  calculation 
will  produce  more  than  100  detailed  intermediate  schedules- -an  impressive 
data  bast  to  start  with.  (Note  that  workload  inequalities  may  result  in  one 
person  having  more  than  the  "average"  number  of  schedules.  This  may 
requiie  two  actions.  Business  Management  should  examine  whether  critical 
areas  of  work  were  missed.  If  this  is  not  the  case,  the  SPD  should  review  his 
assignment  of  resources  to  insure  that  resources  and  workload  have  been 
properly  balanced.) 

With  the  number  of  intermediate  schedules  in  mind,  review  the 
flexible  i  etwork.  Determine  which  events  are  critical  to  the  program  and 
assign  imermei  iate  schedules  to  the  OPRs.  Determine  which  events  require 
significant  infractions  between  external  agencies  and  assign  an 
intermediate  sc  hedule.  Determine  those  events  which  the  "lessons  learned" 
book  indi«  ates  ire  problem  areas  and  assign  intermediate  schedules.  Try  to 
distribute  the  workload  to  all  of  the  divisions.  Every  division  provides 
important  and  ritical  support  to  the  program  and  every  division  should  be 
assigned  intern  ediate  schedule  responsibility. 

Coordinate  the  draft  list  of  intermediate  schedules.  Don't  back  down 
too  soon.  OPRs  will  identify  a  host  of  reasons  why  a  certain  area  is  not  a 
problem  area.  OPRs  will  also  claim  that  insufficient  data  exist  to  make  an 
intermediate  schedule.  Assign  the  OPR  a  reasonable  suspense  and  keep  the 
schedule  on  the  list.  Quickly  accept  any  additions.  The  divisions  are  the 
best  source  for  identifying  critical  activities. 

Have  the  divisions  assign  an  individual  OPR  for  each  of  their  schedules 
during  the  coordination  process.  Try  to  push  the  level  of  responsibility  to 
the  lowest  level  to  improve  communications.  Try  to  avoid  assigning 
schedules  to  division  chiefs,  branch  chiefs  or  group  leaders.  However,  if  a 
supervisor  insists  on  keeping  the  responsibility  at  his  level,  don't  argue.  Let 
him  run  his  shop  his  way. 


Suspenses  and  Coordination.  Assign  a  one  month  suspense  for  the  first 
increment  of  schedules.  Remember  that  developing  an  intermediate 
schedule  does  not  simply  require  putting  a  plan  on  paper.  It  may  require 
making  the  plan.  Require  the  divisions  to  coordinate  their  schedules 
throughout  the  SPO  during  that  month  and  prior  to  the  submission  to 
Business  Management.  This  gives  them  a  chance  to  iron  out  any  of  the  bugs 
in  a  particular  •  chedule. 

After  all  of  the  schedules  have  been  obtained,  publish  them  as  a  draft 
book  and  cirri  late  copies  to  the  divisions  for  comment.  Allow  another 
month  for  the  divisions  to  determine  if  there  are  conflicts  between  the 
schedules  or  it  there  are  conflicts  with  the  contractor's  schedules.  It  is 
important  during  this  period  to  insure  that  the  SPO  has  gotten  it  all 
together. 

• 

The  ne.t  ^tep  is  to  issue  the  revised  book  of  schedules  to  all  external 
agenc  ies.  Sene  one  to  everybody,  especially  those  agencies  tnat  will  provide 
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uppor  t  the  Sl’O.  Identify  to  all  j|  nn  ici  that  the  book  of  intermediate 
•eheduk  lepiesents  when  their  support  is  required  and  will  bei.ome  a 
lequired  lelereme  in  all  MOA's.  This  is  your  opportunity  to  find  out  if  the 
external  support  ran  be  made  available  when  it  is  required.  Allow  the 
agencies  .mother  month  for  review  and  comment. 

Alti  i  comments  are  in,  make  tlie  necessary  revisions  and  issue  the 
lirst  of  In  nil  book  of  intermediate  schedules.  Have  the  book  signed  by  the 
bf’D.  It  now  represents  the  official  program  office  schedule  and  should 
become  a  part  of  the  Program  Management  Plan  by  reference  with  key 
products  m>  hided. 

Schedule-  i  pdates  and  Base  hue  Jrackmg.  All  SPOs  have  a  requirement  for 
baseline  s.  heduie  management.  This  means  that  some  tec  hnique  is  required 
to  identity  and  track  changes  to  the  program  schedule  in  a  Similar  fashion 
that  changes  to  program  costs  are  tracked.  The  intermediate  schedules  can 
provide  this  schedule  management  vehicle. 

tiwiy  two  or  three  months,  have  the  OPRs  update  their  intermediate 
sc  hedulc-s.  The  update  cycle  should  be  based  on  the  extent  of  known  changes 
and  upon  available  resources.  Assemble  the  book  and  coordinate  it 
throughout  the  SPO.  The  coordination  cycle  for  an  update  si  ould  be  less 
than  two  weeks  since  the  majority  of  the  information  will  not  have  changed. 
After  that  cycle,  send  it  to  everybody  once  again.  Again  ask  for  comments, 
integrate  the  comments  and  publish  the  updated,  signed  book  of  schedules. 
The  book  will  serve  as  an  ideal  track  of  all  schedule  <  hanges  and  will  serve 
the  same  function  as  the  cost  track  data  maintained  within  the  SPO. 

Automat  mi,.  The  above  intermediate  scheduling  system  can  be  implemented 
manually  without  automation.  By  distributing  the  workload,  the  average 
individual  should  have  to  prepare  two  milestone  charts  every  three  months  - 
not  an  unreasonable  workload.  However,  automation  has  been  successfully 
applied  to  this  technique  by  the  AFSATCOM  SPO  and  several  others  at  ESD. 
The  automated  technique  uses  a  mini-computer  with  a  plotter  to  draw  the 
schedules.  The  examples  that  follow  (Figures  15  and  16)  were  drawn  by  the 
plotter.  The  benefits  of  automation  are  significant.  The  drudgery  of 
making  the  milestone  charts  and  updates  is  drastically  reduced.  The  OPR 
simply  feeds  his  marked-up  schedule  to  a  secretary  who  inputs  the  data  into 
the  computer.  The  output  is  a  professional  looking  schedule.  This  allows 
the  SPO  to  spend  more  time  in  planning  and  less  time  in  drawing  the  plans. 

An  u  Iditional  set  of  benefits  also  comes  with  automation.  Sorts  of  the 
schedule  data  base  can  be  performed.  The  computer  can  identify  all  events 
which  were  supposed  to  be  complete  by  a  certain  date.  This  generates  a  list 
of  potential  problem  areas  for  review  by  the  SPO.  The  computer  can  also 
generate  a  list  of  events  scheduled  for  completion  in  the  next  30/60/90  days 
to  provide  the  divisions  with  an  activity  forecast.  Other  uses  are  also 

possible. 

1  • 

Getting  the  intermediate  schedules  automated,  however,  can  consume 
i  onsiderul  ie  effort.  Unless  a  system  identical  to  existing  systems  is 


7-4 


proem «  I,  i  SPO  must  expect  to  sp  nd  significant  resoun  e,  in  developing  a 
system,  buying  computer  hardwme  for  this  purpose  is  also  a  difficult 
process.  Hiring  a  contractor  to  establish  the  system  also  is  difficult  and 
drains  sPO  resources  in  the  management  of  another  >  ontiact.  While  the 
long  term  benefits  of  automation  will  outweigh  this  drain,  the  major 
problem  is  that  the  fascination  of  automation  may  detract  from  the  primary 
SPO  objective  -  development  of  intermediate  schedules.  Note  that  the 
computer  will  not  make  the  plans  -  it  only  will  draw  them.  We  recommend 
that  automation  be  deferred  until  after  the  SPO  lias  published  its  first  book 
of  intermediate  schedules  and  worked  ihe  bugs  out.  Robert  Townsend  in  his 
book  of  management  cautions  and  anecdotes  "IJp  the  Organization" 
(reference  1)  gives  sound  advice  here.  He  suggests  that  if  your  current 
system  of  reports  is  not  running  smoothly,  then  putting  it  in  the  computer 
will  only  "speed  up  the  mess."  He  also  advises  that  a  manual  backup 
capability  can  come  in  very  handy. 


Chapter  Seven  References 


1.  Townsend,  Robert,  Up  the  Organization,  Alfred  A.  Knoph,  Inc.,  New 
York,  1970. 
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Figure  15 
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COMPUTING  I  INCUR  TAINT'*  I  OK  A  M.TUOi; 


Introdui  ; < >i  i 

t  |  to  this  point  we  have  rover>  >1  tlie  basic  s<  heck  ling  techniques  and 
laved  out  ihe  approach  and  proceduits  lor  developing  a  Master  Integrated 
Progi.m.  St  hedule  i  omplele  with  a  flexible  network  an  *  I  intermediate 
si  in-.!  ilt  We  have  presented  this  material  in  a  non  quantitative  manner  so 
I  r;  now  we  will  address  the  more  mathematical  aspc  ts  n  some  detail. 

Ibis  >li.  ot  i  t  .mu  t  ntr.ite;.  on  the  methods  we  f  an  use  to  deal  with  the 

in-  v  ii. ild’  in.,  er  taint y  surrounding  schedules  of  program  a<  to  .ties. 

An  to  as  ot  mu  1 1  tuintv  is  not  normally  used  as  a  n  nia  ;ement  control 

i  ■■  hfiiqi.e  r  tor  tin-  ontmuing  effort  of  schedule  maiiitenai  <  e,  although  it 

..n  be  1 1 orpoi  ,ted  as  a  regular  product  of  a  computer-basei  system.  What 
.e  w.ill  , -e  princ  ipally  aiming  at  here  are  the  initial  efforts  during  a  planning 
stage  as  .1  network  is  ronstrut  ted  or  one-time  assessments  or  forecasts  of 
program  progress  to  support  financial  planning,  et<  .  These  techniques  are 
ai>u  use !  1  il  lor  an  independent  Schedule  Assessment,  as  defined  by  AFScR 
ebO-  L\  >  on  iu<  ted  along  with  an  Independent  Cost  An.tlyis  lor  key  program 
■dec  1:  ion  1  te ints. 


basic  hi  K  1  1  'robability 

The  primary  assumptions  used  in  developing  the  PiiRT  statistical 
approach  were: 

1.  The  uncertainty  of  completing  a  schedule  activity  or  task  is  best 
dfcsr  ribed  by  a  Beta  type  of  distribution  lor  the  probability  oi  completion  on 
a  particular  date  or  time  interval.  Figure  17  shows  a  IV  ta  «  urve  for  a  task 
measured  in  weeks  from  start.  The  cumulative  probabil  ty  of  completion  is 
the  total  area  under  the  curve  to  any  point. 

2.  The  curve  must  be  estimated  without  reference  to  any  other 
network  activities  on  the  same  path  or  elsewhere.  Statistical  independence 
is  a  key  ingredient  to  the  calculations  used.  Also,  the  curve  does  not  take 
into  account  unus  al  influences  such  as  accidents,  strikes,  acts  of  God,  or 
any  extraordinary  efforts  to  compress  the  activity  duration. 

The  Beta  distribution  was  selected  because  it  does  tot  have  to  be 
syrninetrit  al  (can  be  skewed  right  or  left),  the  mathemati  a!  behavior  of  the 
urve  is  well  known,  and  thei  e  was  no  better  alternative  that  suited  the 
l’I:K  7  dr  ^  elopers. 
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Task  Duration:  Weeks 
FIGURE  17 


tV  i thou  t  trying  to  get  too  deeply  into  statistical  theory,  there  are  a 
few  basiC  characteristics  of  this  type  of  curve  that  are  used  in  PERT.  The 
most  optimistic  time  occurs  at  point  a  and  represents  a  very  small  chant  e 
(about  1  %)  of  happening.  It  should  be  arrived  at  by  considering  the  shorte.t 
possible  amount  of  time  tor  a  task,  assuming  that  every  thing  went  well. 
Remember,  at  tins  point  the  object. ve  is  to  pin  down  some  of  the  "natural" 
characteristics  of  a  task,  and  there  is  a  length  of  time  that  could  be 
achieved  if  each  subtask  was  accon  plished  in  the  most  time  efficient  way. 
(This  is  not  "crashing,"  however;  no  extraordinary  means  for  shortening  the 
activity  time,  such  as  overtime,  is  assumed.)  The  fact  that  this  time  would 
rarely  (it  ever)  be  achieved  agrees  with  the  1%  probability  of  occurrence. 

The  next  point  on  the  curve  is  the  most  likely  length  of  time  shown  at 
m  or  about  8  weeks.  This  is  simply  the  high  point  on  the  curve,  but  it  does 
not  necessarily  represent  a  cumulative  50%  chance  of  completion  by  that 
date.  In  fact,  it  was  the  intuitive  assumption  that  the  most  likely  time  was 
not  equal  to,  and  usually  earlier  than,  the  >0%  point  that  led  to  the 
start i s t i i  al  treatment  of  3  Time  r  stirnates  in  PERT. 

Hie  final  point  that  must  be  estimated  to  define  the  curve  for  an 
activity  is  the  most  pessimistic  time  b,  or  12  weeks.  This  point  represents 
about  a  79%  chance  ol  completion  or  only  a  1%  chance  of  being  exceeded. 
The  assumption  lor  estimating  b  is  that  everything  required  to  complete  the 
task  takes»tlie  maximum  tune;  everything  goes  wrong  (ah.  Murphy's  Law). 
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\!t>  i  <-si  uua  t  mg  tlit-  Uo  exit,  in’  1 1 1 1 h ■  *»  and  tin  most  likely  time  for 
tin-  in  tiwiy,  the  t  spec  teil  time,  Jp-  *  ,iii  be  c  al<  iilated  L.  the  simple  formula: 

T<  a  i  Or  1 1 1  b 

f» 

Ifi<  expei  ti<J  time  should  appi  iixliuU-  a  “>()%  hunt  •  of  completion 
and  thus  s  the  most  usolul  i  liarai  teristic  of  an  ac  t  vity  lor  laying  out  a 
program  u-twork.  Although  the  formula  is  bimple  c  iouj  h,  the  statistical 
theory  that  barks  it  up  is  lairly  ditlu  ult  to  foflow.  C  ieck  reference  1,  2  or 
i  for  a  detailed  treatment. 

I  he  major  difficulty  with  the  PERT  method  is  obiaining  representative 
estimates  for  the  two  extremes,  a  and  b,  and  the  mo  t  pessimistic  is  more 
difficult  of  the  two  to  got  a  handle  on.  The  most  likt  ly  time  is  much  more 
readily  available  and  probably  is  the  basis  tor  most  milestone  schedules 
already  m  existence  for  a  program.  We  will  present  an  alternative  method 
later  that  ran  hel;  eliminate  some  ol  this  difficulty,  but  the  overall  strength 
and  weakness  of  either  method  lies  in  the  estimating  process  itself. 

The  use  ot  multiple  estimates  lor  an  activity  allows  us  to  construct  a 
network  that  is  much  more  representative  of  the  real-world  problems 
inherent  in  the  program.  It  also  lets  us  make  use  of  mathematical  statistics 
to  characterize  each  activity  and  to  calculate  results  at  the  total  program 
level.  These  results  can  either  quantify  what  we  alr  -ady  felt  was  true  or 
show  that  plans  need  to  b  *  changed  to  modify  the  scheuule  performance. 

On  Hu  other  hand  the  basic  accuracy  (or  inar  uracy)  of  the  inputs 
cannot  be  improved  by  any  form  of  calculation.  Tne  best  we  can  do  is 
structure  the  methods  used  to  derive  the  inputs  sc  the  most  confident 
information  available  can  be  ferreted  out  and  applied  to  the  network. 

PERT  and  Risk  Assessment 

One  of  the  most  powerful  aspects  of  the  statistics  used  in  PERT 
calculations  is  the  approximation  of  the  inherent  spread  or  variance  of 
completion  ^imes  for  an  activity.  For  the  Beta  type  of  distribution  the 
variance  (q-  )  is  given  by  the  formula: 

<r2^  a-b2 

6 

The  standard  deviation  is  simply  the  square  root  of  the  variance  or  one  sixth 
of  the  range  from  the  most  optimistic  to  the  most  pessimistic  time 
estimates. 

I' he  real  benefit  of  this  number  .  omes  as  the  statistical  theory  is  again 
applied  in^two  important  steps: 

1.  1  he  variances  (  2)  of  sequential  activities  (suc  h  as  along  the 

network  t  ritu  al  path)  are  additive  to  give  a  total  variance  for  completing 
the  entire  path,  or  to  any  interim  point  along  the  path. 

v-3 


2.  \tier  uhc  a  turn  oi  iiu.k'  ji  m  acs  .ire  a(kli*d,  1 1 total  dislr ibulioii 
ol  « onipl  t ion  t u in  lor  the  piojn  t  is  .■|>proximalcly  a  iu>i  ual  (symmetrical 
or  bell  snaped)  mi  vt-  Willi  a  variance  oqual  to  tin.-  s.m.  ol  the  individual 
activity  i  or  lances  along  the  <  i  it  u  a  I  pain  of  the  net  woi 

The  second  step  allows  us  to  tal  i-  advantage  ol  the  well  tux  umc-nted 
characteristics  ol  the  normal  distribution  by  virtue  ol  the  most  famous 
theorem  in  statist!'  s:  The  Central  Limit  Theorem  (lor  tl  e  mathematically 
curious  see  reference  2,  page  200).  I  his  simply  means  that  the  possible 
completion  times  for  each  activity  wul  add  up.  to  give  .:  norma)  curve  ol 
probability  tor  the  duration  ol  the  entire  project. 

This  gieatly  simplifies  the  <  aU  illations  along  any  n  twork  path.  All 
we  need  is  the  (enter  point  ol  the  final  curve  and  the  total  variance.  The 
t  enter  point  is  the  expected  nme  lor  the  path  whn  h  is  the  sum  ol  the 
individual  activity  expected  times,  le  (50%  cumulative  robabilityJ.  The 
total  variance  is  the  sum  of  all  activity  variances  on  ne  path,  and  the 
square  root  of  this  total  gives  the  standard  deviation  ol  the  normal  curve. 

For  the  cri  ical  path  of  a  hypothetical  prograr  with  11  major 
activities  on  the  ritieul  path,  the  range  of  uncertaint  in  duration  lor 
completing  the  entire  pioject  is  shown  by  Figure  18.  The  e  .sential  data  are: 

Expected  Time,  Te  ^  -  58. o  months 

Total  Variance,  O'  ;  21.  > 

Standard  Deviation,  <j"  -  4. (.4  months 


Probability 

of 

Completion 


Project  Duration:  Months 
FIGUKl  18 
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A.  list  oru-  example'  of  what  <  an  o<  <  m  m  a  program  s<  luilule,  the 
addition  ut  all  ol  the  most  likely  time  estimates  lor  this  example  gives  52 
months,  which  is  over  6  months  less  than  the  expei  ted  time,  with  only  about 
a  10%  chance  of  occurring.  Moving  up  higher  to  reach  an  84%  total 
confidence  of  completion  takes  63  months  or  I  I  months  longer  than  the 
total  ot  most  likely  times. 

There  are  many  sources  for  tables  of  the  normal  distribution,  but 
Table  I  below  is  a  summary  of  some  of  the  key  points  based  on  adding  or 
subtracting  fractional  values  of  the  standard  deviation  from  the  center  point 
of  the  <  urve.  The  cumulative  probability  for  any  point  is  reached  by 
totaling  the  area  under  the  curve  to  that  point. 


Cum  Probability 

Var  iation 

from 

Cum  Prob.il 

of  Completion 

Te  (XtT  ) 

of  Complet 

1% 

-2.32 

♦  2.32 

99% 

5% 

-1.64 

♦  1.64 

95% 

10% 

- 1-28 

♦  1.28 

90% 

16% 

-1.00 

♦  1.00 

84% 

20% 

-0.84 

♦0.84 

80% 

30% 

-0.52 

♦  0.52 

70% 

40% 

-0.25 

+0.25 

60% 

♦  50% 

-0.00 

+0.00 

50% 

Table  I  (Ref  2,  p.  222) 


Comments  on  PERT  Probability 

There  ate  many  sources  of  analyses  on  the  usefulness,  strengths,  and 
pitfalls  of  the  statistical  approach  used  in  PER  l\  Each  of  the  references 
given  for  this  chapter  deal  with  the  topic  in  much  detail  and  should  be 
examined  for  a  good  understanding.  Reference  1  is  particularly  readable 
and  complete  (see  Chapter  4  and  Appendix  C). 

The  heart  of  the  method  is  the  technique  used  for  the  basic  time 
estimates  for  each  task.  The  use  of  multiple  point  estimates  is  much  more 
useful  than  any  single  time  estimate  because  experience  has  shown  time  and 
again  that  ti  e  single  estimate  won't  happen  and  is  more  often  optimistic 
than  not.  (Statistically,  the  probability  of  single  point  occurrence  is  zero.) 
Even  <  ritics  ot  t  ERT,  CPM,  and  network  techniques  in  general,  agree  that  a 
range  u(  estimates  is  the  best  approach;  the  argument  comes  from  the  math 
used  to  <  omb ne  them. 

Trying  t  '  estimate  the  hypothetical  1%  and  99%  confidence  points  on 
an  assumed  hetu  distribution  is  a  pretty  tricky  business  lor  an  activity  that 
will  oiiui  only  once  and  lias  not  been  done  quite  the  same  way  before,  if 
ever,  t  silig  some  other  type  of  distribution  has  been  suggested,  but  each 
lias  its  own  pitfalls. 
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One  ccay  around  the  problem  sc  ith  estimating  the  key  points  of  a 
distribution  is  a  method  used  in  Operations  Research  or  decision  theory.  In 
this  method  we  estimate  the  probability  of  occurren*  e  of  cei  tain  events,  or 
group  ol  events,  that  will  have  the  greatest  effect  on  the  duration  of  an 
activity.  Tor  instance,  the  time  required  to  prepare  anu  coordinate  a 
Purchase  Request  package  with  all  of  the  supporting  do<  umentution  is 
heavily  dependent  on  the  number  of  problems  that  are  identilied  during  the 
variou .  < •ordination  cycles  and  must  be  corrected  by  revisions.  We  could 
estimate,  based  on  some  prior  experience  and  correlating  with  other 
program  el  forts,  that  the  whole  job  should  take  6  months  with  normal 
problems  (moderate  recycling  for  revisions)  and  about  a  70%  probability  that 
we  will  ,.chieve  this  figure.  The  other  alternatives  are  estimated  at  5 
months  w  .tli  minimum  problems,  but  only  a  10%  chance,  and  7  months  with 
some  major  problems  with  business  strategy,  funding,  etc.,  causing  another 
month  ol  ework  on  the  package,  but  only  about  a  20%  chance  of  happening. 
We  assume  that  one  of  these  3  possibilities  will  occur  (10*70*20  =  100%). 

In  tin  next  section  we  will  show  that  all  of  the  statistical  simplicity  of 
the  PER  I  technique  is  retained  with  this  approach,  and  the  basis  for 
estimatm  is  tied  to  alternatives  within  the  range  of  expertise  available  to  a 
program  office.  It  also  allows  us  to  deal  with  another  network  problem 
more  easi  l> . 

The  other  major  drawback  to  a  strict  PERT  or  CPM  analysis  is  that 
they  both  concentrate  on  the  critical  path  only.  This  becomes  a  problem 
when  the  e  are  a  number  of  other  paths  through  the  network  that  have  a 
mean  or  xpected  time  close  to  the  expected  length  oi  the  critical  path. 
The  unee  tainty  of  completion  (variance)  for  these  parallel  paths  interfere 
with  the  trict  critical  path  results,  and  there  can  be  a  pood  possibility  that 
one  of  these  other  paths  may  exceed  the  critical  path  le  ngth.  The  problem 
is  usually  compounded  by  interactions  between  the  path;  by  either  common 
activities  or  merging  points. 

This  problem  with  PERT  and  CPM  has  been  given  a  good  deal  of 
coverage  in  Operations  Research  and  Management  Science  publications. 
Reference  4  gives  a  good  idea  of  the  order  of  magnitude  of  the  optimistic 
bias  errors  involved  if  the  single  path  treatment  is  used. 

The  example  in  the  reference,  a  fairly  complex  program  (1,100  activi¬ 
ties)  consisting  of  11  identic  al  parallel  projects  and  100  common  ac  tivities, 
was  found  to  be  as  high  as  50%  in  error  (worst  case)  by  comparing  a  critical 
path  calculation  with  a  simulation  involving  the  entire  network.  Even  for 
less  severe  situations  (3  parallel  paths)  the  single  path  length  had  to  be 
increased  by  8  to  2  5%,  depending  on  the  average  variance  of  the  activities. 

Although  some  useful  techniques  will  be  presented  in  the  next  section, 
full  network  simulation  (a  computer-based  technique  using  many 
combinations  of  possible  outcomes  for  all  the  activities)  is  the  best  approach 
if  a  program  contains  many  multiple  paths  through  the  network  that  are 
close  in  expected  length  to  the  critical  path  length.  The  question  to  ask  is: 
"How  close  is  too  <  lose'?"  There  is  a  rule  of  thumb  answe  r. 
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Rekuiue  2,  p.  2  39  shows  mat  il  the  difference  I  tween  the  mean  or 
expet  ted  values  ol  two  parallel  paths  is  greater  than  twa  e  the  larger  of  the 
two  st  a  fatal  (I  deviations,  the  erroi  m  using  the  criti  al  path  only  will  be  less 
than  a  lew  pert  ent.  Ttie  rule  simply  states  that  the  two  distributions  are 
not  "inlet  tei  ring"  with  each  other  and  any  joint  effe<  t  can  be  ignored. 

In  . . .  the  PERT  or  (  PM  statistical  approach  does  have  some 

basic  enoi  sources  and  we  have  covered  two  of  the  major  ones  here: 

1.  the  activity  time  estimating  method,  and 

2.  single  path  analysis  of  uncertainty. 

Both  of  these  can  cause  an  optimistic  bias  in  the  expected  completion 
time  foi  a  |  rograin.  Reference  1,  p.  463,  outlined  the  results  of  a  series  of 
cases  in  winch  the  single  path  analysis  of  uncertainty  caused  10  to  30%  error 
(optimist i»  i.  The  possible  error  in  the  basic  activity  time  estimates  is 
difficult  tt  pin  down,  but  is  potentially  the  largest  consistent  source  of 
errors,  un<:  definitely  the  most  important  part  of  the  whole  process.  This 
leads  to  our  treatment  here  of  a  practical  alternate  method,  which  also 
allows  us  to  deal  with  some  of  the  other  PERT  error  sources. 

Network  A nalys is  with  Discre te  T i me  E stimates 

As  devcribed  earlier,  the  approach  is  based  on  estimating  several 
alternatives  for  an  activity  with  each  tied  to  the  possibility  of  a  discrete 
event,  or  group  of  events,  o  curring  that  will  have  the  greatest  effect  on 
the  time  needed  to  complete  the  activity.  The  objec  tives  of  this  method  are 
to  aid  the  estimator  by  relati  ig  the  task  duration  to  effects  within  our  grasp 
of  person.  1  experience  or  resources  and  to  still  retain  the  simplicity  of 
uncertainty  calculations  for  the  network.  It  even  allows  us  to  apply  some 
full  netwoik  statistical  calculations,  if  the  network  is  relaiively  simple  or 
computer  resources  are  available  for  simulation. 

As  described  in  the  previous  section,  this  approach  associates  a  time 
estimate  with  the  probability  of  occurrence  for  that  particular  task  length. 
The  sum  of  all  of  the  discreie  probabilities  for  the  alternatives  must  equal 
100%,  since  oik*  must  occur.  This  section  will  concentrate  on  the  network 
calculatioi  s  used  w'ith  this  method  and  what  the  results  look  like. 

The  nutation  used,  for  i  onvenience,  is  shown  in  Figure  19  below.  The 
activity  0-1  is  estimated  with  three  alternative  durations:  6  months  with  a 
50%  probability:  6(.5);  S  months  with  a  30%  probability:  8(.3);  and  10  months 
with  20%:  10(.2). 


6(.5) 

8(.3) 

I0(.2) 


=  7.4  months 
=  2.44 

=  1.56  months 


Figure  19 


f 


I  in  n-  ate  .evcral  way.  to  dt\  with  ilus  <its<  rt-te  typ<  ol  ■  tatistical 
distrr -lit  i.»n,  but  we  will  uv  the  sit  plest  lirst  (Rclerciv  e  5,  p.  91-95).  To 
calculate  the  expet  ted  or  mean  tim<  multiply  each  alternative  length  by  the 
probability  ot  occurrence  and  sum  tin  products.  In  this  case: 

Te  6  x  .50  .  8  x  .30  i  10  x  .20  7.4  months 

The  variance  (or  spread)  is  given  by  squaring  the  difference  between 
each  time  estimate  and  the  mean,  multiplying  again  by  the  associated 
probability,  and  adding  the  products,  or: 

(7.4-6)"  x  .50  +  (7.'t-8)2  x.iOr  (7.4- 10)2  x  .20  -  2.44 

Tin-  standard  deviation  is  the  square  root  of  this: 

<S  \/r2. 44  1.56  montus 

With  these  parameters  we  can  proceed  with  the  same  single  path 
probability  calculations  as  shown  with  PERT.  That  is,  the  expected  length 
of  a  path  is  the  sum  of  the  activity  expected  lengths  and  the  total  path 
variai,  i*  is  given  by  the  sum  of  the  activity  variances.  We  can  also  apply 
the  Central  Limit  Theorem  for  about  four  or  more  activities  in  series  to 
give  .  n  approximately  normal  final  distribution,  as  before,  with  the  variance 
and  mean  known. 

So  the  estimating  process  can  be  improved  while  still  keeping  the 
simplicity  of  calculation  that  PERI  gives.  But,  for  "trouble  spots"  in  the 
network  where  the  single  path  analysis  is  in  ern  r,  we  can  use  another 
appro  a  n  to  deaf  with  interferring  purailel  paths. 

In  this  cast  we  assume  two  activities  are  constrained  at  the  start  and 
completion  events,  as  shown  in  Figure  20,  the  expected  times  are  close  to 
the  same  length,  and  the  standard  deviation  of  the  shorter  path  is  large 
compared  to  the  mean. 


7(.2)  Te?  =  10  months 

10(.5)  *  --  3.0 

1 2(.  3)  =  1.73  months 


6(.l)  Te.  -  9.9  montln 

8(.6)  if*  ;  11.49 

15(.3)  -  3.38  months 


Figure  20 
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lo  *  al>  ulute  the  effect  of  both  a>  1 1 v i t i< together  we  must  find  t he* 
joint  probability  .list!  ibution  and  tlu  n  c  ale  ulate  the  expected  tn  >e  and 
vai  lam  e  1 1  otn  it . 

The  joint  distribution  defines  ull  ol  the  pc.  able  i  ombinai  >ns  of 
completion  times  toi  both  activities  along  with  the  probability  that  any  pair 
of  times  will  ex  e  ur  together.  The  longest  time  of  the  pair  is  chosen  for  the 
joint  probabilities  bei  a  use  it  is  the  one  that  os  is  trail',  me  distribution  (both 
must  be  completed).  In  this  Case  the  probability  ol  task  0-1  taking  10 
months  is  *>0%  and  that  ol  task  0  2  for  a  15  month  dotation  is  30%.  The 
probability  of  both  of  these  alternatives  cx  <  urrmg  c.  ihc  product  « »j  their 
individual  probabilities  or  .“>0  x  .  <0  .  .15,  or  a  I  V>  <  nance.  But,  f  this 

happened,  task  0-2  would  constiain  the-  total  rumple!  i  hi  to  a  15  month  total, 
so  we  get  a  joint  probability  ol  15  (.15). 

The  total  distr ibu tioii  <  an  he  vet  up  m  a  simple  a .  >  t  u  x  *.! town  m  able  2. 
I  ur  each  intersection  in  the  main',  the  piobabihtes  ate  mnltiphed  and  the 
longest  tune  ol  the  pair  is  chosen.  We  then  add  .ill  th<-  probabilities  for  any 
given  length  that  occurs  in  the  product  matrix  to  get  il.’  total  distribution. 


Parallel  -  Joint  Probability  Matri» 


Task  0-1 

Joint  Distribution 

12( . 3 ) 

1 2 ( .03 ) 

1 2 ( . 18) 

..  _ 

1 5 ( .09  ) 

10  ( .  5  ) 

10 ( .05 ) 

1 0  ( -  30 ) 

1  5  ( .  1  5 ) 

7 ( ./  ) 

7 ( .02 ) 

8  ( .  1 2 ) 

1  5  (.06) 

6  ( .  1 ) 

8(.6) 

I5(.3) 

Task  0-2 
Table  2 


Table  3  sltows  the  resulting  distribution  and  the  new  values  of 
the  expec  ted  time  and  the  variance.  The  expected  time  is  increased  by  16% 
and  the  joint  standard  deviation  is  inbetween  the  two  original  values. 


loint  Probability  Results 


Task  I  ength  (Probability) 


15 

12 

10 

8 

7 


(.09 
(.0  1 
(.O') 
(.12) 
(.02) 


.15  i 

.18) 

.30) 


TOTALS: 


.06) 


(.30) 
(.21) 
(.35) 
(.12) 
CO  2) 

(1.00) 


To  11.6  riioiitbs  vs  10.0  from  single  path 
<S  2  6.38 

<f  2.5  months  vs  1.7  and  3.4 


Table  3 


This  procedu  e  can  be  used  in  simple  cases  throughout  the  network  to 
take  major  interactions  into  account  by  condensing  them  into  single 
equivalent  activities.  Large  scale  interactions,  su<  h  as  long  parallel  paths 
must  be  treated  by  some  form  of  computer  simulation.  The  matrix 
calculations  get  out  of  hand  quickly! 

The  important  thing  to  remember  is  that  after  you  have  identified  areas 
of  a  program  schedule  that  will  cause  errors  in  a  cr i t i<  al  path  analysis,  they 
must  be  dealt  with  somehow.  Even  a  "seat  of  the  pants"  addition  of  10  to 
10%  to  account  for  the  optimistic  bias  in  the  mean  is  better  than  nothing. 
Hut  if  you  can  deal  with  these  areas  quantitatively,  the  rule  of  thumb  or 
management  judgement  can  be  left  for  issues  that  really  don't  have  a  better 
alternative.  The  schedule  starts  losing  its  value  as  a  well  disciplined 
communication  device  if  we  let  "windage"  calculations  take  over. 

The  discrete  probability  calculations  can  also  be  used  to  condense  more 
complex  areas  in  the  schedule.  This  is  done  in  steps  to  combine  sequential 
activities  and  then  the  equivalent  parallel  elements.  Figure  21  shows  a 
typical  problem  area  that  cannot  be  treated  with  the  critical  path  only,  and 
it  can  be  reduced  to  a  single  equivalent  activity. 
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Series/Parallcl  Interac  lion 


2(.2)  I  t-  4 


4(.2) 

Figure  21 

Th  •  critical  path,  0- 1-3-5,  gives  an  expec  ted  duration  of  12.4  months 
with  a  standard  ieviation  of  1.8  months.  Both  of  the  other  possible  paths 
give  total  expected  times  less  than  one  standard  deviation  from  the  critical 
path  value:  0-2-4-5  =  11.6  months,  and  0- 1-4-5  -  12  months. 

The  first  step  is  to  combine  the  series  activit  es  0-2  and  2-4  and  the 
same  with  0-1  and  1-4.  This  is  done  with  another  simple  matrix  of  the  same 
form  a-.  Table  2,  except  the  activity  durations  are  added  for  each  joint  pair 
since  the  two  at  e  occurring  in  sequence.  Table  4  show's  the  matrix  and 
results  lor  combining  activities  0-2  and  2-4. 


Series  -  Joint  Probability  Matrix 


isk  0-2 

Joint  Distribution  | 

•  2) 

3(.04) 

5(.  1 2) 

7(.04) 

_ 

4(.  12) 

6(.36) 

8(.  12) 

2) 

5(-04) 

'  7  (.12) 

9134 r 

2(2) 

4(.6) 

6(.2) 

Task  2-4 


Result:  0-2-4 


3(.04) 
4(.  12) 
5(.  16) 
6(.36) 
7(.  16) 
8(.  12) 
9(.04) 


TABLE  4 


Tin  .  iii  it-  husu  proi  tilure  is  used  to  tin-  |..iralh-l  -joint  probabilities 
lor  paths  h-2-4  in  <  .injunction  with  path  0-1-'*  (n  U-ren<  <•  Table  2).  Then 
activity  4  i  is  added  in  a  series  matrix  calculation  giving  a  single  distribu¬ 
tion  that  accounts  lor  path  .0-2-4- 5  and  the  rife  ts  of  intersecting  path 
0-1-4. 


The  next  step  is  to  run  the  straight  series  calculations  (or  the  critical 
path  0-1-  t  ■>.  Again  combining  by  matrix  torm  and  two  at  a  ime.  First  0-1 
is  combined  with  1-3  and  that  result  with  3-5.  ( Nq t < • ;  the  ar  thmetic  is  a  lot 
easiei  if  you  round  off  sensibly  and  throw  out  insignifi*  ui  t  points  in  the 
intermed. ate  results,  or  program  it  in  your  cak  ulator!) 

The  final  mati  ix  is  a  parallel  <  ombinatiori  of  the  two  major  path 
results,  and  in  this  case  it  contained  9x8  elements.  The  detailed 
calculations  lor  this  example  were  run  in  about  an  hour  and  a  half  with  only 
a  simple  i  alculator.  As  discussed  earlier,  this  example  is  m  obvious  *  ase 
where  single  path  treatment  is  not  very  accurate  and  the  results  bear  that 
out.  The  critical  path  gives  an  expected  time  of  12.4  months  while  the 
matrix  combinations  give  14.4  months  for  the  50%  confident  *  point.  In  this 
case  the  standard  deviation  was  almost  identical:  1.8  moi  ths  single  path 
versus  1.84  months  for  the  whole  network,  but  there  is  no  intuitive  way  to 
find  that  out  beforehand. 

Full  Network  Simulation 


If  you  are  fortunate  enough  to  have  the  access  to  computer  resources 
with  a  networking  capability,  the  best  way  to  treat  this  typ  *  of  problem  is 
to  make  multiple  runs  of  the  entire  network.  In  a  Monte  Carlo  simulation 
the  discrete  probability  estimates  for  the  duration  for  ea  h  activity  are 
coupled  with  random  number  generators.  So,  with  each  "run*  one  duration  is 
randomly  st  lected  from  the  possibilities  for  every  activity  n  the  network, 
and  then  a  (  ritical  path  analysis  is  done  giving  the  total  project  duration  for 
that  run  and  all  the  activities  that  were  on  the  critical  path.  As  the  number 
of  runs  made  increases,  the  times  selected  for  each  task  by  the  Monte  Carlo 
method  begin  to  approach  the  dis*.  rete  estimates.  That  is,  for  an  estimate 
of  8  months  and  60%,  the  number  of  times  8  months  is  selected  will 
approach  60%  of  the  total  number  of  runs. 

A  full  network  simulation  may  give  many  different  cr  tical  paths  and 
one  useful  output  is  the  number  of  times  that  a  specific  activity  was  on  the 
critical  path  or  its  "criticality"  to  the  program.  Reference  6  shows  a  system 
that  has  been  used  on  some  Navy  programs.  It  is  based  *>n  full  network 
simulation  and  gives  outputs  such  as  task  criticality  and  a  spectrum  of 
earliest  and  latest  start  and  complete  dates  for  each  activiiy.  It  will  also 
at  cept  various  probability  distributions,  including  the  discre  e  type  wt  have 
been  using  here. 

What  we«have  presented  in  this  chapter  are  some  techniques  that  can  be 
used  manually,  but  they  are  also  adaptable  to  a  range  of  automated 
treatments  starting  with  programmable  calculators  to  do  the  matrix  arith¬ 
metic. 
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KVIatii.^  I  'nij.  rt.imty  and  Risk 

No  miller  which  quantituti  .e  nu-thod  is  uvd  oui  objective  is  to  express 
the  to Lt !  din  t  ol  the  individual  elements  of  si  bed  ile  uncertainty  on 
program  lompletion.  The  keys  .ire  to  establish  a  clear  set  ol  ground  rules 
lor  estimating  schedule  ranges  lor  activities,  nlentifv  interactions  and 
inter  dependencies,  and  use  a  consistent  and  explu  it  method  lor  combining 
these  in  tidal. 

Altho  igh  getting  to  this  point  may  seem  an  insurmountable  workload,  a 
tmal  siht  iule  with  completion  dates  expressed  as  a  confidence  range  is  only 
the  first  ngredient  (or  risk  assessment.  Uncertainty  t  alculations  give  us 
answers  to  questions  like:  "When  will  I  have  a  7  5%  confidence  of 
completio  lV  Risk  assessment  attempts  to  quantify  the  impact  of  a  25% 
chain  e  ot  not  completing  hy  that  same  date. 

We  c  innot  make  the-  point  too  strongly  that  schedule  performance  is 
intimately  related  to  the  *  ost  .md  technical  sides  if  program  performance. 
T.ach  side  cart  only  be  separated  as  a  one  dimensional  look  at  a  3-D  problem. 
There  are  always  impacts,  and  the  trick  is  to  tie  the  schedule  range  to  the 
other  two  parameters  in  any  way  possible. 

Summary 

In  this  chapter  we  have  covered  some  lairly  straight-forward  methods 
for  ilealin  ;  with  schedule  uncertainty  in  a  quantitative  fashion.  We  looked 
at  the  PERT  probability  treatment,  some  of  its  shortcomings,  and  presented 
several  w.  ys  around  PERT  or  Cf’.VI  problem  areas. 

Statistical  methods  cun  be  employed  to  quantify  the  collective  wisdom 
of  program  participants  about  when  tasks  will  be  completed.  The  results 
can  be  used  to  define  risks  inherent  in  plans  and  budgets.  The  methods  used 
should  not  add  significantly  to  the  normal  errors  in  the  basic  estimating 
process,  so  improvements  to  the  input  data  (i.e.  by  adi  ing  sources)  should 
increase  the  overall  accuracy. 
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APPENDIX  A 


LIST  OP  ACRONYMS 

At  -  ESD  Comptroller  organization 
A1 PE  -  Automatic  lata  Processing  Equipment 
Ai  CC  -  Air  Force  < ommunicat ions  Command 
AFLC  -  Air-  Force  Logistics  Command 

AFSATCOM  -  Air  Force  Satellite  Communications  Program  Office  (ESD/DCK) 

AFSC  -  Air  Force  Systems  Command 

AFSC  Form  L6  -  AFSC  Program  Direction 

AMETA  -  Army  Management  Engineering  Training  Activity 

ATE  -  Automatic  Test  Equipment 

BA  -  Budget  Authorization 

CA  -  Contract  Award 

CAR  -  Command  Assessment  Review 

CCB  -  Configuration  Control  Board 

CPC  -  Computer  Program  Component 

CPCI  -  Computer  Program  Configuration  Item 

CPM  -  Critical  Path  Method 

CPR  -  Cost  Performance  Report 

CRISP  -  Computer  Resources  Integrated  Support  Plan 

C/SCSC  -  Cost/Schedule  Control  Systems  Criteria 

DCP  -  Decision  Coordination  Paper 

DE  -  ESD  Civil  Engineering  organization 

D&F  -  Determination  and  Findings 

DSMC  -  Defence  Systems  Management  College 

DT&E  -  Development  Test  and  Evaluation 

EEC  -  Earlie.t  Expected  Completion  time 

A- 1 
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ilfi  tfoi.ic  Syst  ms  Division 


FCA/P  A  -  Functional  configuration  Aue  i  t/i'hysic.i  i  Cor, figuration  Audit 

LIFE  -  Govtrni.ent  Furnished  Equipment 

IG  -  Inspecti!'  General 

ILS  -  Integrated  Logistics  Support 

I ESP  -  Integrated  Logi sties  Support  PI  a. 

IOC  -  Initial  Operational  Capability 

10T&E  -  Initial  Operational  Test  and  Evaluation 

JAG  -  Judge  Advocate  General 

LAC  -  Latest  Allowable  Completion  time 

MIPS  -  Mastei  Integrated  Program  Schedule 

MITRE  -  MIT  i eseareh  Engineers  Corp.  -  ESD's  Systems  Engineering  support 
Federal  Contract  Research  Center. 

MOA  -  Memorar dum  of  Agreement 

OPR  -  Office  of  Primary  Responsibility 

PCO  -  Purcha. ing  Contracting  Officer 

PERT  -  Program  Evaluation  and  Review  Technique 

PK  -  ESD  Cont  racts  organization 

PMAG  -  Program  Man  igement  Assistance  Group  -  HQ  AFSC 

PMD  -  Program  Management  Direction 

PME  -  Prime  f  ission  Equipment 

PMP  -  P-ogran,  Management  Plan 

PR  -  Purchas-  Request  (AFSC/AFLC  Form  36) 

PWBS  -  Progr.  m  Wor  <  Breakdown  Structure 
RFP  -  Request  for  Proposal 

SACDIN  -  Strategic  Air  Command  Digital  Network  Program  Office  (ESD/DCV) 
SPD  -  System  Program  Director  (also  called  SPO  Director) 

SPG  -  System  Program  Office  (used  same  as  Program  Office  here) 
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SOW  -  Statement  of  Work 


TKMP  -  Tf.ii  and  Kvaluation  Master  l  lan 

TIPI  -  Ta<  tical  Information  Processing  arid  Irit  -i pretation  Program  Office 
(ESI  'DCH-1 ) 

TO  -  fISD  Technical  Operations  organization 
W:.S  -  Work  Breakdown  Structure 
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